Wierd behaviour - Laz 1.6 >> Laz 2.2

[BrunoK]

Also in the Call Stack window, change max 25 to the biggest value you can set. That is required to help determine the origin of the instruction causing your error.

[Martin_fr]

Well the first stack is interesting.

Line 22 "Loaded"

The current code in "TDateEdit.Loaded;" was added in
   Revision: 8ce29506c500e46d65b9a067bf446fd91224e6c0
   Date: 02/02/2017 12:33:18
   TDateEdit: Don't change empty Text when toggling DirectInput in designer. Part of Issue #0030425.


1.6 was released before this. 1.6.4 was released shortly after, but likely this wasn't merged (I didn't check).

So what does it do?
"Loaded" is called when the LFM has been read and applied. So all the properties you did set in the object inspector have now been loaded.

"Loaded" (since that change) calls

Code: Pascal  [Select][+][-]

1.     SetDate(FDate);

And that triggers the EditChange event.

That did not happen before (not in 1.6), because when the date is set while the component is loading the LFM, events are not fired  (if all goes correct).
E.g.

Code: Pascal  [Select][+][-]

1. procedure TCustomEdit.TextChanged;
2. ...
3.     if ([csLoading,csDestroying]*ComponentState=[]) then  // not while loading
4. ...
5.       Change;  // calls event
6.  

Due to this change the event is now fired (IMHO that is not correct  / it is also not part of what the commit message describes as indented change) immediately after the lfm was loaded, way to early.

[Martin_fr]

As a workaround you may be able to prefix your event with something like

Code: Pascal  [Select][+][-]

1. if not Form1.isVisible then exit;

Probably also works with "sender.isVisible".

[J-G]

MARTIN!! 

Have you found the issue ??

Reading your last but one response it seems that you might have   ---   I've just checked the exact version of Laz that my project works in and it is definitely 1.6 not 1.64  so your logic that there was a change after that causing "Loaded" to call 'SetDate(FDate);' too early does seem sound.

I have to presume that the 'workaround' you suggest would have to be appled wherever I use a 'DateChange' which would explain why the error moved to the 'DatePaidChange' proc. which is the next 'DateChange' in the list of 7 total - so that's not too onerous, and it will be a write once copy many (or a few)  job

At least I now have some logical reason and a potential solution.

I'll add the work-around and report back.

[J-G]

!! HOORAY !!

Well, speaking a little in advance but the 'DATA Not Initialized' message has not been fired after I appled the 'work-around'.

I've been using a clean 'copy' of the program on a different hard drive from where my 'Live' data is located so naturally it assumes a 'first time' and asks exactly what I would expect.

I'll now have a short break and take my evening meal before I put the 'work-around' into the live program.


Is this something that ought to have a bug-report? If so, since I've never been in a position to profer such, is there anything I can provide to assist?

[Martin_fr]

Reading your last but one response it seems that you might have   ---   I've just checked the exact version of Laz that my project works in and it is definitely 1.6 not 1.64  so your logic that there was a change after that causing "Loaded" to call 'SetDate(FDate);' too early does seem sound.

Yes, you read that correctly. This is what I think is the cause (or at least one of them if there were to be several....)

Adding an this, it is also quite possible that because the event fires before the form is visible (or even has a handle), the event (either your code, or the LCL) subsequently triggers something that causes the exit/crash.... That is speculation, but IMHO plausible.

I have to presume that the 'workaround' you suggest would have to be appled wherever I use a 'DateChange'

Yes.

And then we have to see, if the exit problem is solved by this, or if there is more.

Just one more thought. I do expect at that time that Form1 <> nil.
But if not, that check needs to be added, and exit the event too, if it is nil.

[Martin_fr]

overlapped posts

Is this something that ought to have a bug-report? If so, since I've never been in a position to profer such, is there anything I can provide to assist?

Not for now.

I've reported it internally. I'll see if I get any update

[J-G]

Good news  -  and not quite so good news 

Yes, the work-around solves the 'Wierd' behaviour problem so the project runs under Laz 2.2. I've checked all the salient features   --  naturally some only come up at end of quarter or end of year so they will have to be checked when those events arise but I am rather more confident than I was yesterday!

A small irritation - which is associated with a 'Date' component - arises only on the first time that I switch between [Customer] & [Supplier]. This entails 'Clearing' the Supplier or Customer  Record which includes a TDateEdit and I was setting the .Text property to ''  - thus:

Code: Pascal  [Select][+][-]

1.   Form1.PurInv.Caption    :='';
2.   Form1.DatePaid.text     :='';    <-------   here
3.   Form1.PayMeth.ItemIndex := 0;

which threw a 'Cannot focus a disabled or invisible window'. At the time of calling, the component is invisible but it didn't cause a problem in Laz 1.6.   The warning does allow a 'Click OK to ignore' and doing so allowed the program to continue and switching between [Customer] & [Supplier] didn't cause a problem again - the component remains invisible and has never been visible - it will become visible at a later stage of course.

I've been able to comment out the assignment and eliminated the issue but, as it concerns a TDateEdit component, it might have a bearing upon the initial problem.

It's been an 'interesting' few days and I'm very grateful to Martin for his stalwart help in guiding me around parts of the IDE that I've not previously had occasion to investigate.

[Martin_fr]

Code: Pascal  [Select][+][-]

1.   Form1.PurInv.Caption    :='';
2.   Form1.DatePaid.text     :='';    <-------   here
3.   Form1.PayMeth.ItemIndex := 0;

which threw a 'Cannot focus a disabled or invisible window'. At the time of calling, the component is invisible but it didn't cause a problem in Laz 1.6.   The warning does allow a 'Click OK to ignore' and doing so allowed the program to continue and switching between [Customer] & [Supplier] didn't cause a problem again - the component remains invisible and has never been visible - it will become visible at a later stage of course.

Can it be reproduced in a simple test/demo app?

If so, should probably be reported as bug.

Otherwise: Callstack?

[BrunoK]

  Form1.DatePaid.text     :='';    <-------   here

As previously suggested, move the bloody UI initialization code to TForm1.onshow or TForm1.OnActivate.

DatePaid.OnChange or TaxPointe.OnChange, a SetFocus or something similar that requires the form to be completely activated.

[J-G]

[...]
Can it be reproduced in a simple test/demo app?

If so, should probably be reported as bug.

Otherwise: Callstack?

Couldn't (quickly) re-create in a small test but I do have CallStacks immediately before the Error.

The CallStack at line 2 in the code fragment (true 3329) is ScreenGrab 8  and using [F7]  takes me to Control.inc line 5109 and the CallStack at line 5117 is ScreenGrab 9.

[F7] at that point fires the error shown by ScreenGrab 10; [Continue] then shows the message at ScreenGrab 11 and [OK] gets me into the program fully with no further errors.

[Martin_fr]

When the "Debugger Exception Notification" with "Break"/"Continue" dialog comes, you should do "break". That will pause the app, and the "raise Exception" will be in the Call stack => so at this point the stack is of interest

I can't get the exception with just a TDateEdit on the form.
I suspect the assignment triggers an event, and your code in the event may do something.

[MarkMLl]

As previously suggested, move the bloody UI initialization code to TForm1.onshow or TForm1.OnActivate.

HOLD IT. The fact that the error comes up when he's switching from one part of the UI to another implies that this isn't in an OnCreate() event handler.

Having said which, I've just checked and I've been moving code routinely between 1.6.4 (FPC 3.0.2) i386 (i.e. not just the original 1.6) and 2.2.0 (FPC 3.2.2) x86_64. So I don't think the IDE issue that Martin's spotted is the only problem, and there might be something else related to the way J-G's (ab)using one of the components that's changed between 1.6 and 2.2.

MarkMLl

[Bart]

Is this something that ought to have a bug-report? If so, since I've never been in a position to profer such, is there anything I can provide to assist?

Not for now.

I've reported it internally. I'll see if I get any update

I'm looking into it.

Bart

[J-G]

When the "Debugger Exception Notification" with "Break"/"Continue" dialog comes, you should do "break". That will pause the app, and the "raise Exception" will be in the Call stack => so at this point the stack is of interest

I can't get the exception with just a TDateEdit on the form.
I suspect the assignment triggers an event, and your code in the event may do something.

Apologies, Martin, I'd thought that the state imediately before that would be more telling

Fortunately I can turn the problem on/off with a simple    // comment   on line 3329 of the .PAS file so attached is ScreenGrab 12 which is the state imediately after [Break].


I also tried with just a TDateEdit and a TButton - without success - but which [Event] may be triggered is a mystery since after  line 3329  the trace goes to 'Control.inc' :-

Code: Pascal  [Select][+][-]

1. procedure TControl.SetText(const Value: TCaption);
2. begin
3.   //if CompareText(Name,'MainForm')=0 then debugln('TControl.SetText A ',DbgSName(Self),' GetText="',GetText,'" Value="',Value,'" FCaption="',FCaption,'"');
4.   if GetText = Value then Exit;
5.  
6.   // Check if SetTextBuf is overridden, otherwise
7.   // we can call RealSetText directly
8.   if TMethod(@Self.SetTextBuf).Code = Pointer(@TControl.SetTextBuf)
9.   then begin
10.     RealSetText(Value);                   <<<<<<   Error fired  here
11.   end
12.   else begin
13.     // Bummer, we have to do it the compatible way.
14.     DebugLn('Note: SetTextBuf is overridden for: ', Classname);
15.     SetTextBuf(PChar(Value));
16.   end;
17.