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
On 08/04/15 14:58, Donald Ziesig wrote:
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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
