Does TObject have all the capabilities of TComponent apart from things like streaming and being used from the IDE component palette?

I want to create an object which has all the capabilities like getting and setting properties, and I want to know whether I need to inherit from TObject or from something further down the hierarchy.

Another aspect is ownership. Does ownership require objects to be derived from TComponent?

Is a TPersistent adequate if manipulating the object from the IDE isn't needed?

Last but not the least, is the FreePascal TObject/TComponent system more or less the same as Delphi's, or are there some major differences?

Do you mean setting properties during runtime or just using the concept of properties?

Properties themselves are already supported by TObject, for setting properties at runtime the RTTI must be enabled which is done by surrounding your class declaration with "{$M+}...{$M-}". Then "published" will be enabled to allow the streaming of properties. Alternatively you can derive from TPersistent which has RTTI already enabled.

Another aspect is ownership. Does ownership require objects to be derived from TComponent?

I believe that's introduced by TComponent, but it could also be further up... (ok... according to
http://www.freepascal.org/docs-html/rtl/classes/tcomponent.html I'm right ^^ )

Is a TPersistent adequate if manipulating the object from the IDE isn't needed?

I'm sorry, but I don't understand what you mean here.

Last but not the least, is the FreePascal TObject/TComponent system more or less the same as Delphi's, or are there some major differences?

Basically they are the same, but it might be that Lazarus has an extra TLCLComponent inheriting from TComponent...

Regards,
Sven

According to what I have read in the WIKI you only install components into Lazarus if they are visual and you really need them to be part of a visual form.
In all other cases you should not install a component in the IDE, instead you instantiate the objects from that component in code.

I think that from this follows that you can base such a class on TObject rather than TComponent for all "normal" uses.

TObject also has properties:

TMyObject = class(TObject)
  FMyProp: Cardinal;
private
  function  GetMyProp: Cardinal;
  procedure SetMyprop(Value: Cardinal);
protected
public
  property MyProp: Cardinal read GetMyProp write SetMyprop;
end;

A setter and a getter are connected to the property as a gobetween to the field that holds the value itself..

Message: 5
Date: Mon, 15 Nov 2010 16:32:34 +0100
From: Bo Berglund
Subject: Re: [Lazarus] When do I need a component rather than a plain object?
To:
Message-ID:
Content-Type: text/plain; charset=us-ascii

On, 15 Nov 2010 16:32:34 +0100, Bo Berglund

You create and install a component, not because it is visual or non-visual
but because you wish to use it in the visual forms designer in Lazarus, just as in Delphi. For example TTimer is not a visual component, but because you wish to add it to the component palette and add it to your form, it has to be a descendent of TComponent.

If you are creating a visual component it should be a descendent of TControl or one of it's descendants.

TPersistent is the base class that implements support for the streaming subsystem used by the forms designer and it's components to save their properties in the form file.

If you don't wish any of these facilities, you can use TObject.

Yes I understand what you say, but why not create the TTimer in code instead and not put it into a form where it will not show up in runtime?
Of course my discussion is not about the built-in IDE components but rather about self-developed non-visual components. These should NOT be installed in the IDE and the corresponding objects created in code instead. Then one gets more control (see below).

What I was getting at is this:
Any component that you want to put visually on a form requires that component to be installed in the IDE, which also means that its sources are stored within the Lazarus own folder tree. But in a software development environment with many developers working on many projects where these components are used there is a problem of ensuring that the components are up to date within the projects. We faced this many times when developing with Delphi because we fell into the trap of creating "components" instead of ordinary classes for stuff that had no visuality in teh programs. It was sort of a convenience that you could drop for instance a logging component onto your main form and then set its properties in the designer. But the component had no visual part and should not have been a component in the first place.

We stopped this and instead create normal classes based on TObject. These can then be checked out into a project source tree very much apart from the IDE folder tree. Here we have full control and can be sure that we can tag all project files so that we can get back to an old state when we need to fix user bug reports.
And the classes used in a project will be easily updated to the latest state as part of the general project source update from CVS (yes we use CVS...).
In the component case we always had to "know" that we also needed to update the IDE components in a different place to get the latest and we could not tag the project in one place and be sure that we tagged all sources...

Now that we are stuck with a lot of component stuff from old times we have stopped installing them in the IDE. We just use tham as normal classes and we create them as needed in the project start code and it works just fine. The sources are checked out into each project that use them and this means that a tag on the project will hit them too. So we can recreate the exact situation for a user version that has a bug and fix it.

Of course this holds for all components tha are non-visual, which most of ours were. But we do have stuff that are visual too, and here we have to install in teh IDE but then (in Delphi) we make sure that there is no global path to the component sources so we can add the component sources to the project module and check out as usual. Then we set the project search path to include these local copies. It seems to work but is a bit of a hassle.

You can do that as well. Nobody can stop you from creating a TTimer same is true for visual components as well.
It's up to you what you prefer.

As said above you are free to do it as you want. Another one might love to put his/her non-visual components on the form and then the he/she must install the component in the IDE.

Wrong.

Basically it works like this (in Lazarus):
- you create a package and register units that have components that need to be visible
- you can use this package without installing it in the IDE. Then your applications will find the units that are provided by the package, but you can't put them on a form
- you can install this package inside the IDE, so first part of the above statement still holds, but you can also put them on a form

This package can be anywhere on your system. The IDE will just compile itself with that package like it would compile a common application (did you already play around with Lazarus packages? I suggest you to do it :) ). I myself have multiple 3rd party components in my version controlled package directory and at least the lNet components are installed in the IDE.

At my workplace we have a common svn repository with our 3rd party components. Those components are installed inside the Delphi IDE. We also have two other repositories where design time packages are located (our own components) and those can be installed in the IDE as well (switching between versions of our products doesn't work correctly, but I'm working on that).

Regards,
Sven

I realized the wisdom of Bo's approach to creating components at run-time and setting the properties in code only 2 days go.

I overwrote some of my newer code with older code, and although I restored the *.pas from git, I forgot about the*.lfm where the SQL was stored. It was only hours later that I realized the the update code was in the components that I restored it.

Initialzing non-visual components from form properties is an evil which is best avoided.

It will be good if Lazarus can generate the source code to initialize components at the start of a program, rather than stream them in, hopefully in a future version. It makes revision control much easier, a lot more transparent.

Op 2010-11-16 11:45, Frank Church het geskryf:

It will be good if Lazarus can generate the source code to initialize components at the start of a program, rather than stream them in, hopefully in a future version. It makes revision control much easier, a lot more transparent.

Interestingly, this is exactly why I took the "generate source code instead of a form file" approach with fpGUI's UI Designer. One unit to worry about, predictable creation order, easy search-and-replace of components or properties (refactoring or global changes etc), components can be in the private section of forms where they belong, form upgrades to new or changed properties are easy to handle, easier form loading with high tolerance for error handling etc, etc...

I think Lazarus would benefit much from such an addition to it's form designer. Pascal was supposed to be an easy language. So why emulate the C-style (multiple files requirement) in Pascal?

Other toolkits that also generate source code from their Visual Form Designers are Visual Studio with .NET, Qt Designer, KDE Designer, etc.

Regards,
- Graeme -

I think your mileage may vary. I work with lots of custom components in Delphi and Lazarus (in fact, I never use the 'standard' ones, always descendants or third-party components, installed in the IDE). In 12 years, I never experienced any of the problems you describe. Not in Lazarus, not in Delphi.

So I cannot say that my experience supports your conclusion.

It will be good if Lazarus can generate the source code to initialize components at the start of a program, rather than stream them in, hopefully in a future version. It makes revision control much easier, a lot more transparent.

I am all for such a feature (to each his own, after all), but I don't think it solves any real problems. You admitted you made a mistake in your VCS, but you blame the lazarus way of doing for it. This is definitely not logical to me.

Michael.

Op 2010-11-16 12:32, Michael Van Canneyt het geskryf:

In 12 years, I never experienced any of the problems you describe. Not in Lazarus, not in Delphi. So I cannot say that my experience supports your conclusion.

We used to use Team Coherence (and old VCS that is dying a slow death) that actually had a feature to help developers with exactly that. You could setup file groups and and it had some known groups pre-setup for you. So in TC you only saw the .pas files, but checking out a .pas, also checked out the associated .dfm file (if it had one). It had similar pre-setup groups for Delphi's project or package files too.

So I guess some other developers also made such mistakes for TC to have such a feature. ;-) It was pretty handy though.

Regards,
- Graeme -

lfm files are simple text files just like pascal sources, so a revision control system works the same.

There is a writer to write forms as pascal source (see examples/pascalstream). But some properties can not be streamed, as there is no simple source equivalent. For example images and icons. They must be handled differently.
There are some other minor issues too.

The other big part is the reading the source code back to a form at design time. That part is missing completely.

I lack some imagination what the benefits are, except for smart linking. Apparently some people have started such approach for Lazarus, but never got feedback or help to continue, so I guess the work outweighs the benefits.

Pascal was supposed to be an easy language.

So is lfm. At least I never heard complains that the lfm format is hard to read.

So why emulate the C-style (multiple files requirement) in Pascal?

Readability.
The form data easily grows to thousands of lines (e.g. icons). Putting that into the source code breaks the readability rule to keep every file small. And it is normally completely auto created and edited by the IDE, so you very seldom edit it in code.

lfm files are loaded as resources. This can save some memory.

Other toolkits that also generate source code from their Visual Form Designers are Visual Studio with .NET, Qt Designer, KDE Designer, etc.

Anyone is welcome to start a wiki page and/or extend the pascal form reader/writer. When it works it can be added to the IDE as a third type of resource.

Mattias

It's the first thing I remove. I inadvertantly destroyed this generated-and-folded code on more than one occasion :(

Just to say that use cases vary. There is no one-size-fits-all solution.

Michael.

Op 2010-11-16 14:19, Mattias Gaertner het geskryf:

lfm files are simple text files just like pascal sources, so a revision control system works the same.

I'm not saying it's hard to read lfm (text versions), I'm simply saying it's an extra file the developer and VCS needs to managed. For one, the developer needs to remember to commit the lfm file in sync with the .pas file in the same revision. With today's VCSes that have atomic commits (I think that's the right term) where a commit is related to all files in the repository, this is not so much of a problem these days (at least for checking out files). In the days of Team Coherence, Source Safe, CVS where a commit was per file, and as in TC and SS where you had to physically check-out those files before you could edit them, it was a bit of a pain. But yeah, this is mostly irrelevant these days with SubVersion, Git, Mercurial etc supporting atomic commits.

there is no simple source equivalent. For example images and icons.

In fpGUI, I use the same method as 'bin2obj', making such resources simply arrays of bytes. For readability (before Lazarus supported user defined code folding) I stored those in include files, but this is not required any more - see below.

Not necessarily, if you use code folding (which is on by default in Lazarus IDE). fpGUI's UI Designer creates code as follows:

procedure TMainForm.AfterCreate;
begin
  {%region 'Auto-generated GUI code' -fold}   [...]
end;

So with Lazarus IDE's code folding, by default the above is all that the developer will see, unless they expand that code-folding region themselves.

Regards,
- Graeme -

Op 2010-11-16 14:45, Michael Van Canneyt het geskryf:

It's the first thing I remove. I inadvertantly destroyed this generated-and-folded code on more than one occasion :(

As far as I can recall you said in was the code-folding support in Lazarus IDE that caused you problems. You never mentioned exactly what those problems where though.

Highlighting code and pressing the delete key is an issue with the developer, not the software. ;-)

Just to say that use cases vary. There is no one-size-fits-all solution.

This is true. I was simply highlighting the fact that auto-generated code doesn't need to overwhelm the developers editor, it can be hidden from view. If I recall (from 7 years ago), Visual Studio did [does] exactly the same.

Regards,
- Graeme -

Op 2010-11-16 14:45, Michael Van Canneyt het geskryf:

> So with Lazarus IDE's code folding, by default the above is all that the > developer will see, unless they expand that code-folding region themselves. It's the first thing I remove.

Added to my todo list:
* Add a user defined option if the fpGUI Designer must place auto-generated code in a code folding region or not.

Regards,
- Graeme -

And then?

Image.Data := ...

... or search a word. Then the region is unfolded and not automatically folded.

Graeme, you are right, that putting the form data into the unit is sometimes nicer. I just think that this not always the case. And in my experience for medium/big projects I prefer to keep them separate. I guess that is just a matter of workflow.

Mattias

Op 2010-11-16 15:13, Mattias Gaertner het geskryf:

In a nutshell, yes. fpGUI's image handling is not identical to LCL's though. Below is example code of loading and registering a new image with an application.

  fpgImages.AddMaskedBMP('tadmin.edit',  @tadmin_edit16,
      sizeof(tadmin_edit16), 0,0 );
  fpgImages.AddBMP('tadmin.copy',  @tadmin_copy16,
      sizeof(tadmin_copy16));

tadmin_edit16 is the image array identifier. The string name (first parameter) is what I call an "image alias" and can be anything the developer wants. Once registered, you can get a reference to that image from anywhere inside the application by simply calling.

  img := fpgImages.GetImage('tadmin.edit');

sometimes nicer. I just think that this not always the case. And in my experience for medium/big projects I prefer to keep them separate. I guess that is just a matter of workflow.

Yes, it's a what you are used to or personal preference I guess.

Regards,
- Graeme -

And where is that image array identifier defined? (I believe that's the point that Matthias wants to know)

Regards,
Sven

The problem is moot in fpGUI, it doesn't have a TImage component. Drawing an image must be done manually using Canvas.Draw, so a hypothetical IDE for it must not worry about it :-)

Michael.

On, 15 Nov 2010 16:32:34 +0100, Bo Berglund

What I was getting at is this: Any component that you want to put visually on a form requires that component to be installed in the IDE, which also means that its sources are stored within the Lazarus own folder tree.

There is NO requirement for a visual component to be placed on the IDE component palette. You place a component on the palette to provide design time access to it in the forms designer. This access has nothing to do with a component being a visual or non-visual one. You can instantiate a TTimer or a TListBox from code if you wish.

The source can be anywhere. The directory needs to be in the list of directories searched for units in the Compiler Options dialogue.

But in a software development environment with many developers working on many projects where these components are used there is a problem of ensuring that the components are up to date within the projects.

There is indeed, it is called "Packages"

We faced this many times when developing with Delphi because we fell

into

It can be much more than a "convenience". It gives you the possibility of
providing design-time support for your component. eg the Fields Editor for a database table. Or the Action Editor for TAction for example. It also
provides the support for things like the addition of event skeletons in the
code editor.

We stopped this and instead create normal classes based on TObject.

Just because you don't include it in the IDE doesn't mean it can't be a TComponent descendent (or TControl or TButton descendent). You are free to write a listbox descendent and NOT include it in the IDE. It can be
the easiest option if you are writing a new component, visual or non- visual, for example.

Frank Church wrote

I overwrote some of my newer code with older code, and although I restored the *.pas from git, I forgot about the*.lfm where the SQL

was

stored. It was only hours later that I realized the the update code

was

in the components that I restored it.

Bo's approach doesn't solve this problem; You still need the same files
for the Visual Components, and what about include files, resource files,
image files etc. If you use a source control product, you have to ensure
that you restore ALL the files required, you can't pick and choose. Hopefully, git has an option or options to do this for you, otherwise it's
a waste of space.

Initialzing non-visual components from form properties is an evil

which

is best avoided.

Why limit your ire to non-visual components? If it's evil for non-visual
components, surely your ire needs to be redirected to all components. Why should I have to initialise TTimer in code but I can use the forms designer for a TButton.

It will be good if Lazarus can generate the source code to initialize components at the start of a program, rather than stream them in,

hopefully

in a future version. It makes revision control much easier, a lot more transparent.

God's teeth! The unit for the form would, potentially, be huge! Again, it doesn't
help with source control either. You still have to manage all the other non-
pascal files in your project such as include files, resource files, images etc.
If your source control package can handle these, it should be able to handle
form files too. If it can't, you should be shopping for a new one.

Op 2010-11-16 16:18, Sven Barth het geskryf:

And where is that image array identifier defined? (I believe that's the point that Matthias wants to know)

Ah ok, that is for the developer to decide. Inside the same unit the image is needed (eg: implementation section const), or my preference, inside a "resource" style unit (eg: myappimages.pas).

As I mentioned, images are simply byte arrays that looks as follows:

Const
tadmin_export16 : Array[0..823] of byte = (
66, 77, 56, 3, 0, 0, 0, 0, 0, 0, 54, 0, 0, 0, 40, 0, 0, 0, 16, 0, 0, 0, 16, 0, 0, 0, 1, 0, 24, 0, 0, 0, 0, 0,

      .... );

I'm currently working on improvements in the fpGUI Designer so location, conversions, image property editors etc of images all happens inside the Designer. The developer can already set image alias for various components, but image conversion (to a byte array) is still done via a small utility application. This should all be improved on in the next few days.

Bottom line is that even if a "forms designer" generates source code, images or other resources can still be used.

Regards,
- Graeme -

Op 2010-11-16 16:39, Michael Van Canneyt het geskryf:

The problem is moot in fpGUI, it doesn't have a TImage component.

Yes, yes, and takes all of two minutes to implement, if really needed. :) In the case of fpGUI, I haven't yet had such a need. With fpGUI Designer having the ability to drop any "unknown" widget on a form (that's any TfpgWidget descendant that's not registered in the component palette), and being able to setup properties for that widget even though it is "unknown", I had no need to implement a dedicated TImage type component yet.

It's similar to me not seeing the point of the various "Dialog" (file open, font select, color select etc) components on the component palette - it's equally easy using them directly in code when needed. There is no advantage of having design time support for those - in fact it just uses extra memory when you do.

If you really want a TImage style component, all you had to do was ask and I would have implemented it :) Either way, I'll implement one just just for you (though it might be a bit later I guess). ;-)

Drawing an image must be done manually using Canvas.Draw, so a hypothetical IDE for it must not worry about it :-)

But image selection is still required (and possible in fpGUI) for other components that display images. eg Buttons.

Regards,
- Graeme -

I don't agree. I use the IDE to the fullest - it is RAD after all. But use cases vary.

If you really want a TImage style component, all you had to do was ask and I would have implemented it :) Either way, I'll implement one just just for you (though it might be a bit later I guess). ;-)

No need, I did that myself. You better spend time on more useful things :)

Michael.

Just out of curiosity (might be OT):

Does that fpgImages class have methods for loading images from resources or must that be done manually?

I really need to work more with fpGUI... especially if I want to improve its Windows Mobile 5+ support :P

Regards,
Sven

I am not blaming Lazarus as such, as Delphi does the same, but when I do a diff of a .lfm file it is obvious to me that things would be much clearer from source code generated at runtime, rather than looking at the properties text in source. Runtime source code can also be formatted properly or even have an order of generation so stuff don't get move around much. It can even be generated in separate files, or as Graeme said in some private section of the file.

Eg. when you move components around sometimes for the sake of accessing other components properties to change them, it creates a lot of noise in the diffs, as positions in most cases are irrelevant to a lot of components.

Setting properties in code is fine, and some design IDE component can be used to generate the source code to initialize be honest it is something I noticed some time ago, but never realized how hard it could hit if you made some error or forgot about something.

Perhaps Graeme will permit the inclusion of that kind of facility into Lazarus in some future version, and component designers can include it in their component design.

Frank Church kirjoitti tiistai 16 marraskuu 2010 21:54:39:

There is also another related but little different problem with .lfm diffs. When I touch a form that someone else has committed into revision control, the Top, Left, Height and Width properties of all controls change. I don't need to change the layout or any property for it to happen. This was annoying when multiple people made changes to the Build Lazarus dialog. I edited some small thing but in commit history it looks like a massive layout change.
If I understand right it is caused by different widgetsets and themes and whatever. There is no change in the actual layout (all controls are anchored) but it adds noise to the commit history.

Is there any way to prevent it, except for editing the diff manually (or using the line resolution commit system with a local git repo)?

Juha

Op 2010-11-16 17:31, Michael Van Canneyt het geskryf:

Just curious and a bit off-topic I guess, but is there some advantage to have the various dialog components dropped on a form at design time? As I said, I think it just takes up memory while not being used, but honestly can't think of a single advantage it gives.

As for the "RAD" part, you still need to write code to actually execute the dialog and read back the result and do some processing (saving, loading, change a font, change a color etc). So "RAD" is really not much use for those dialog components.

Regards,
- Graeme -

Op 2010-11-16 17:31, Sven Barth het geskryf:

Does that fpgImages class have methods for loading images from resources or must that be done manually?

If you mean the new FPC resources, then probably no. I haven't looked at the FPC resource functionality at all yet.

Regards,
- Graeme -

Op 2010-11-17 01:22, Juha Manninen het geskryf:

If I understand right it is caused by different widgetsets and themes and whatever. There is no change in the actual layout (all controls are anchored) but it adds noise to the commit history.

That is a problem indeed (even for non-Lazarus developers, but simply somebody that wants to send in a patch). I never bothered to research why it happens though.

Also, what happens if I used 112 dpi (as my X11 server automatically detected on my work PC) on my desktop, and you use 96dpi hard-coded under Windows (as it does by default)? My laptop again has 135dpi because it's a very high resolution screen.

I presume that is what causes all Lazarus IDE dialogs to looks as follows? Lots and lots of clipping, incorrect positioning of components etc.. See attached image.

Regards,
- Graeme -

The only advantage that I am aware of (at least in Delphi): you can execute the dialog from within the IDE (although I've never used it up until just now ^^).

Right click on the dialog -> test dialog

Regards,
SVen

Graeme Geldenhuys wrote

Just curious and a bit off-topic I guess, but is there some advantage to have the various dialog components dropped on a form at design time?

MSEgui filedialog components for example have a "statfile" property to save and restore their state in a central tstatfile component. It is also possible to link several filedialogs. The setting of the many properties is most convenient by means of the object inspector, the event properties are handy too.

Martin

Op 2010-11-17 10:33, Sven Barth het geskryf:

Right click on the dialog -> test dialog

Um, never knew about that feature.

Regards,
- Graeme -

The Stored function of the Left/Top/Width/Height can be optimized to write less unneeded values. But some code might depend on the values at loading end and needs to be fixed. So this is an incompatible change. I'm not sure how to handle this.

That is probably the TButtonPanel bug. The problem is that I can not reproduce it here.

Mattias

Il 17/11/2010 07:56, Graeme Geldenhuys ha scritto:

I presume that is what causes all Lazarus IDE dialogs to looks as follows? Lots and lots of clipping, incorrect positioning of components etc.. See attached image.

I have the same behaviour on Lazarus 0.9.29 r28292 FPC 2.4.2 i386-win32-win32/win64

-------------- next part --------------
A non-text attachment was scrubbed...
Name: project.jpg
Type: image/jpeg
Size: 16451 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101117/ebc9e4f0/attachment.jpg>

2010/11/16 Frank Church

Thought about it recently, I think that having some IDE menu item "Paste as code" (for objects as text in clipboard) or external tool would be grea. And even if IDE doesn't have it, it's ok, I'll be glad living with a tool :). I see at least two ways to implement this

1. Converting the text to single call with incoming text accurately fitted to 'bla-bla-bla''#1310+ lines. The format of this text is exactly the same as text from lfm/dfm, just converted to be compatible pascal string constant

PROS:
- easy to implement, one even doesn't have to know anything about the text format, just use the routines Lazarus uses itself.
- theoretically the same tool/wizard can also accept this fragment back in order to temporal designer edit since the conversion is not so complex CONS:
- rtti info have to be available at the time of creating so either explicitly the code should contain RegisterClass call or the developer should remember about this (correcting the statement after the first run).
- component references can not be automatically resolved
- if some property was changed/removed, only run-time error for corrections would be possible

2. Other way is to convert it to correct pascal assignments/calls (the latter for TStringList, TCollection etc)
PROS:
- compile-time errors for everything: absent uses entry, non-existing property etc, not-resolved component reference assigment.
- easy and safe in-place editing also with a little help of the compiler. CONS:
- much harder to implement, one must know everything about the text lfm/dfm format for correct conversion.
-also much harder to implement backward conversion.

Did I forget something? Is it something also deserved to be mentioned?

Thanks,

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101117/0f57fca4/attachment.html>

Hello Lazarus-List,

Wednesday, November 17, 2010, 12:41:26 PM, you wrote:

AM> Il 17/11/2010 07:56, Graeme Geldenhuys ha scritto:

> I presume that is what causes all Lazarus IDE dialogs to looks as follows? > Lots and lots of clipping, incorrect positioning of components etc.. See > attached image.

AM> I have the same behaviour on Lazarus 0.9.29 r28292 FPC 2.4.2 AM> i386-win32-win32/win64

Same here also. fpc 2.5.1 16316, Lazarus r 28156, WIN XP SP3 32 bits. This problem starts sometime in october because my last update was in september.

17.11.2010 9:56, Graeme Geldenhuys ?????:

Lots and lots of clipping, incorrect positioning of components etc..

Examples?

See attached image.

It is a bug of TButtonPanel.

See http://bugs.freepascal.org/view.php?id=17791.
Please leave a comment there, in what OS/Widgetset you reproduced this bug.

Just noticed (I don't know if you have tested that): this works in Lazarus as well (in the context menu as well as by double clicking the dialog component). :D

Regards,
Sven