Lazarus

Using the Lazarus IDE => Designer => Topic started by: MarkMLl on March 03, 2019, 09:20:44 pm

Title: Forms and frames
Post by: MarkMLl on March 03, 2019, 09:20:44 pm
When a form embeds a frame, it's possible to edit the properties of controls embedded in the frame from the form's designer window. Shouldn't those be read-only in inaccessible?

I know I've been caught by this one before. This time round I'd got a frame containing a TDrawGrid with 1024 rows, but that was getting changed to 1000 rows at some point between creation and use. I eventually grepped and found it in the form's .lfm file.

MarkMLl
Title: Re: Forms and frames
Post by: af0815 on March 04, 2019, 08:43:27 am
If youclose the form and reopen it, it is synced with the frame. So if you change something in the framedefinition you must closeand reopen the form in wich the frame is embedded.
This is oneof the reason, i  load a frame only at runtime.
Title: Re: Forms and frames
Post by: MarkMLl on March 04, 2019, 01:04:36 pm
If you close the form and reopen it it saves the outline of the frame, but not any properties of controls embedded in the frame. That's entirely reasonable.

If you use the form's designer to change properties of a control embedded in a frame, those changes get embedded in the form's .lfm and quietly override the properties defined in the frame (i.e. which are stored in the frame's .lfm). At that point properties which one would expect to be private to the frame can no longer be changed in the frame's designer: they appear to be changed at design time but they get overridden at runtime and the only way to fix that it to delete the frame from the form.

I'd have expected the content of a frame to be inaccessible or read-only to the form's designer.

MarkMLl
Title: Re: Forms and frames
Post by: valdir.marcos on May 21, 2019, 06:05:09 pm
When a form embeds a frame, it's possible to edit the properties of controls embedded in the frame from the form's designer window. Shouldn't those be read-only in inaccessible?
I know I've been caught by this one before. This time round I'd got a frame containing a TDrawGrid with 1024 rows, but that was getting changed to 1000 rows at some point between creation and use. I eventually grepped and found it in the form's .lfm file.

If youclose the form and reopen it, it is synced with the frame. So if you change something in the framedefinition you must closeand reopen the form in wich the frame is embedded.
This is oneof the reason, i  load a frame only at runtime.

If you close the form and reopen it it saves the outline of the frame, but not any properties of controls embedded in the frame. That's entirely reasonable.
If you use the form's designer to change properties of a control embedded in a frame, those changes get embedded in the form's .lfm and quietly override the properties defined in the frame (i.e. which are stored in the frame's .lfm). At that point properties which one would expect to be private to the frame can no longer be changed in the frame's designer: they appear to be changed at design time but they get overridden at runtime and the only way to fix that it to delete the frame from the form.
I'd have expected the content of a frame to be inaccessible or read-only to the form's designer.
If you still think that is not correct, please open a bug report at:
https://bugs.freepascal.org/my_view_page.php