Re: [Lazarus] Very strange errors when editing programs using Frames

2015-04-08 Thread Donald Ziesig

On 04/08/2015 05:01 PM, Mattias Gaertner wrote:

On Wed, 08 Apr 2015 09:58:32 -0400
Donald Ziesig  wrote:


[...]
(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.

Do you mean "Position" or "Left", "Top"?

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.

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 ;-) .

Please create a bug report.


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


Mattias

--
___
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


Re: [Lazarus] Very strange errors when editing programs using Frames

2015-04-08 Thread Mattias Gaertner
On Wed, 08 Apr 2015 09:58:32 -0400
Donald Ziesig  wrote:

>[...]
> (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.

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

 
> 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 ;-) .

Please create a bug report.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Very strange errors when editing programs using Frames

2015-04-08 Thread Mattias Gaertner
On Wed, 08 Apr 2015 15:42:12 +0100
Tony Whyman  wrote:

>[...]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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Very strange errors when editing programs using Frames

2015-04-08 Thread Tony Whyman

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