Hi All!

I'm not sure if the following is a new bug or whether it only occurs in Lazarus for Windows
1.4RC2 or RC3.

I have been testing Lazarus 1.4RC2 and now Lazarus 1.4RC3 on Windows 7 and have encountered
strange behavior with frames. I have simplified the code down to an app that displays
a very simple frame after a button push. There is only one *unusual* factor in this app
(but it is common to many programs I wrote in Delphi and Lazarus for Linux). That is,
I subclass TFrame to add functionality to all descendent frames, for example:

TFrameX = class(TFrame)

       public Print; virtual;   // Now the main program can call Print
on a framex and
                                         // the frame-specific printing
occurs.
       constructor Create; override;
     end;

the remainder of the frames in the apps are subclassed from TFrameX.

TFrame1 = class(TFrameX) ...

The issue is that when editing the MAIN program's appearance using the Object Inspector,
(specifically changing *Position*), the .lfm file for the FRAME /occasionally/ gets an entry
for*Position*! (sometimes *TabOrder*, too.). I can't pinpoint exactly the time at which
this extraneous data appears, but it doing a series of normal editing operations such as
moving the windows, changing the properties of the MAIN or FRAME for a few minutes
(but not changing the code) will definitely cause it to happen. Once it does, the object
inspector for Frame1 has an entry for *Position* (and sometimes *TabOrder*) which is not
present when a frame is first created. After this appears, reloading the Frame form
will /sometimes/ raise an exception in the IDE complaining about the unknown property
for the Frame.

The intermittent (apparently) nature of this is puzzling.

Subsequently, when I attempt to run the program, one of two possible situations occur:

1. Clicking on the button that displays the frame calls the code but does not display
the frame, or,
2. Clicking on the button raises an exception describing the extraneous entry in the
.lfm file.

I haven't been able to figure out why one or the other happens, but for any given
compilation the error remains the same.

I have a simple app that demonstrates this problem if anyone would like to try to
replicate my troubles ;-) .

Thanks,

Don Ziesig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150408/4ad0dce9/attachment-0001.html>

Don,

Welcome to the wonderful world of Lazarus frames!

I use them a lot including subclassed frames as you are doing. They are very useful for structuring complex forms as well as common elements, but the IDE will bite you back if you are not careful. I don't think I have seen exactly what you have, but I have seen many strange behaviours.

The main advice I would give is to make sure that when you are editing a frame, all forms using that frame are closed. Otherwise, the IDE typically decides that any properties you update in the frame do not apply to the form's instance of the frame and overrides them. The worst case is when you add an event to a component on the original frame. If any forms using that frame are open, that event usually gets set to "none" on the form and you have to edit the .lfm to restore sanity. Getting used to editing lfm files is one of the delights of using frames as it is the only way of recovering from the IDE overriding property values in using forms - Lazarus unfortunately does not have the Delphi Object Inspector's "revert to inherited" option.

In many cases I have it found it more reliable to add a frame programmatically in the form's "loaded" method. That way you ensure that the IDE does not helpfully modify properties for you. If you do do that, beware, for some reason "loaded" can get called more than once for each form.

Tony Whyman
MWA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150408/ac682f08/attachment.html>

[...]Lazarus unfortunately does not have the Delphi Object Inspector's "revert to inherited" option.

Now it has.

I implemented it only for some basic types and it works only for TComponent properties. So it does not work for Label1.Font.Color, because Font is not a TComponent.

Mattias

Do you mean "Position" or "Left", "Top"?
"TabOrder" is a normal TFrame property. It is set automatically by the LCL for all controls.

Please create a bug report.

Mattias

Position as in poDesigned

"TabOrder" is a normal TFrame property. It is set automatically by the LCL for all controls.

This may be true, but one of the errors is an exception caused by an invalid property "TabOrder".
It doesn't happen frequently, but I have seen it more than once.

Will do (as soon as I return to Windows ;-) ).