Wierd behaviour - Laz 1.6 >> Laz 2.2

[J-G]

I've had a need to edit a project that was originally written under FPC3.0.0/Laz 1.6 but I'm now using 3.2.2/2.2.0 - Opening the project in Laz 2.2 was no problem but compiling, even with a debugging break at the very first line of [FormCreate] fired a 'ShowMessage' that should only appear after I'd tried to call a procedure before I'd initialized the basic data.

Under Laz 1.6 everything works as expected.

Even with[DeBugging] turned off the message still fires as it does if I select GNU or fpDebug backend.

I can't even think what sort of information might help anyone try to offer some sort of advice - but I would appreciate your thoughts !

Fortunately, returning the project to Laz 1.6 it compiles and runs OK.

[Martin_fr]

Opening the project in Laz 2.2 was no problem but compiling, even with a debugging break at the very first line of [FormCreate] fired a 'ShowMessage' that should only appear after I'd tried to call a procedure before I'd initialized the basic data.

The description isn't that clear....

1) "but compiling"  => something happens while compiling?
2) "debugging break at the very first line" => something happens when running/debugging?

For now, I'll assume 2.
" debugging break at the very first line of [FormCreate] fired a 'ShowMessage' that should only appear after"

There is lots of code before "FormCreate".

a) If your LCL has debug info, find the "ShowMessage" implementation in the LCL, and set a break there.

b) Open menu Project > View Project Source
That is where the Pascal code starts, and you may want to set a breakpoint.
Except: Any "initialization" block of any unit may still run even before that.

Even with[DeBugging] turned off the message still fires as it does if I select GNU or fpDebug backend.

And there we are back, is that a message by the IDE - that comes while compiling, or when the debugger starts?
Or is that a message that your app displays while running (despite you do not expect your app to do so)?

I can't even think what sort of information might help anyone try to offer some sort of advice - but I would appreciate your thoughts !

Some bit of the code?

Compile without optimization.

[J-G]

Thanks for the input Martin - and apologies for my inept attempt at describing the problem 

Compilation 'appears' to complete .... in fact to do any further work I HAVE to close the program using [Ctrl][F2]  so the program is running but doesn't show the intial screen.

Here is a snippet of Code :

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

1.   if not DataInitialized then
2.     begin
3.       showmessage('DATA Not Initialized');
4.       Exit;
5.     end;
6.  

That appears a number of times since there are quite a few TButtons which could be clicked before the basic data has been initialized.  This is my accounts package so the first thing I need to do is select a [Year] and the 'Data' can only be determined once the year is selected. 

I had actually tried a breakpoint at the start of the .LPR file as well - with the same result.

I've now made a copy of the project on to a differnt hard drive for testing under Laz 2.2. With a breakpoint at "  RequireDerivedFormResource:=True;" which doesn't get called before there is an IDE message [exit-code 217]   - - - - -   on the next 'Compile' (F9) the break IS actioned  ??????    and I then see the 'Data Not Initialized'  message at   " Application.CreateForm(TForm1, Form1);"

This is quite an old project and I now see something that I consider 'Odd' in the .LPR file :

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

1. uses
2.   {$IFDEF UNIX}{$IFDEF UseCThreads}
3.   cthreads,
4.   {$ENDIF}{$ENDIF}
5.   Interfaces, // this includes the LCL widgetset
6.   Forms, SalesLedger, printer4lazarus, runtimetypeinfocontrols
7.   { you can add units after this };
8.  

I have no idea why 'Forms, SalesLedger, printer4lazarus, runtimetypeinfocontrols' is here rather than at the top of the main .PAS file ???? (which is 'SalesLedger')

As I've said, there is no problem under Laz 1.6.

[MarkMLl]

That's quite a big jump. I've definitely got a couple of things that I try to keep running on a fairly wide range of versions, but I'd rather not check right now just /how/ wide.

The thing that immediately springs to mind- although it appears to apply to the wrong direction- is the change in .lpi (?) format somewhere around 2.0: unless you can restore from a VCS I'd suggest you don't save any file using the later IDE for the moment.

Does the project look right when you open it in the IDE? Can you see the main form?

MarkMLl

[J-G]

The project looks quite 'normal' - Form, Object Inspector, Watches etc. are all there.

I have many other projects originally written under 1.6 which don't show (haven't shown) problems but this is by far the largest with nearly 18k lines and 15+ TPanels on a single Form.

I've even (inadvertantly - through double clicking!) re-opened projects in 1.6 that had been edited in 2.2 with no ill effects.

Regrettably, I have no idea what a 'VCS' might be.

[KodeZwerg]

Regrettably, I have no idea what a 'VCS' might be.

Version Control System, just a guess 

[Martin_fr]

I've now made a copy of the project on to a differnt hard drive for testing under Laz 2.2. With a breakpoint at "  RequireDerivedFormResource:=True;" which doesn't get called before there is an IDE message [exit-code 217]   

217 that could be
https://www.freepascal.org/docs-html/user/userap4.html

217 Unhandled exception occurred

But then it should be caught, in the debugger.
If indeed this is a run error, make sure to put "sysutils" very early in the uses clause of the "project source" (right after cthreads, outside the ifdef). Then in should be converted to an exception.


Getting different behaviour on different runs => not good. Points to memory corruption. Some pointer access .....

Did you compile with NO optimization?


go to Tools > configure build lazarus
In custom options put:  -gw -O- -Criot
That will add debug info to lcl, if it hadn't been there yet.
Then try debugging again....

[J-G]

Hmmmm...

Thanks for the input again Martin but you are taking me on a journey that is well outside my understanding 

I think I understand what you say but now compilation fails with many (nay numerous!) Warnings, Hints and lastly Errors such as 'Identifier not found'  "FloatToStr", "IntToStr" and "Now"

This is now the Uses Clause in the .PAS file :

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

1. uses
2.   Classes, {SysUtils,} FileUtil, Windows,
3.   RTTICtrls, PrintersDlgs, Forms,
4.   Printers, Controls, Graphics, Dialogs,
5.   StdCtrls, EditBtn, ExtCtrls, Arrow,
6.   Grids, ActnList, Menus, DateUtils,
7.   LCLIntf, Buttons, ComCtrls, JGDT
8.   ;
9.  

... and this is in the .LPR File :

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

1. uses
2.   {$IFDEF UNIX}{$IFDEF UseCThreads}
3.   cthreads,
4.   {$ENDIF}{$ENDIF}
5.   SysUtils,
6.   Interfaces, // this includes the LCL widgetset
7.   Forms,
8.   SalesLedger,
9.   printer4lazarus,
10.   runtimetypeinfocontrols
11.   { you can add units after this };
12.  

I suspect that since I am not using 'Threads', I could remove everything before the 'SysUtils' entry and I can't understand why 'Forms' is in both 

I've just removed 'Forms' from the .LPR file and get the same set of errors. . . .

A further look at [Tools][Configure "Build Lazarus"] I see that I'd left Profile to Build as 'Normal IDE' with Options  -gw -O- -Criot  and if I change that to  'Debug IDE' the options change to  -gw3 -gl -gh -gt -Co -Cr -Ci -Sa    . . . . .

As I said at the start, I'm well out of my comfort zone so I haven't tried a compile with this setting.

[KodeZwerg]

I've just removed 'Forms' from the .LPR file and get the same set of errors. . . .

"Forms" must be in .lpr file for GUI applications!

make sure to put "sysutils" very early in the uses clause

He said to put it very early and not to comment it out 

[jamie]

I've got a couple of questions.

 1.What button types are attached to this ShowMessage prompt?


 2.What I found various times, especially moving projects around to different laz installs is there is a corrupt debug break point sitting in the break points list, many pointing to address instead of line numbers etc. You should check the break point list out and clear them all because it will cause all kinds of strange things to happen when your code fires up.

[J-G]

[...]
He said to put it very early and not to comment it out 

I put it in the .LPR  instead of the .PAS.

With your assertion that 'Forms' must be in the .LPR - which means that it is also in the .PAS - I've now assumed that SysUtils may also be in both and that allowed a compile    but with the same ultimate result  -  "DATA Not Initialized" at   Application.CreateForm(TForm1, Form1); 

I've never noticed before that 'Forms' is automatically added to the .LPR file     -  I very seldom need to view that file.

[Martin_fr]

lastly Errors such as 'Identifier not found'  "FloatToStr", "IntToStr" and "Now"

Overall not enough to keep guessing.

But the above brings up a potential point. At least IntToStr (but maybe also Float...) have new overloads. If the error is "cant find overloaded ..." or similar.
Then basically your argument does not exactly much the declaration in fpc. and you may have to do "IntToStr(Itnt64(your_val))" (or the same with QWord for unsigned).


But those are compilation errors. They should have been there at the very start. I don't get however your project did get to even run before.
So, before even trying to get any further debugging: Make sure a "clean build" succeeds.

If you get compile errors:
If unsure: verbatim error message (feel free to take the unit name out).
And the code to which it points, incl declaration of vars and types in the statement.

3rd party packages?
Open each, and at the right of the toolbar is an overflow dropdown => "compile clean"

Ideally install a separate copy, in a separate folder for any 3rd party package. Mind you may need to open them by hand (from lpk) to teach lazarus the new path.

[J-G]

You'll probably see that I've understood why I got those  "FloatToStr" etc. errors  -  I'd deleted SysUtils from the .PAS file  -  I did say I didn't fully understand your instruction!

This program has been operational for at least 8 years (compiled under Laz 1.6) so there must be something 'silly' that I'm not seeing in 2.2.

I must retire since it's now past 1:30am and I have a funeral to attend in the morning so I'm unlikely to respond again until at least very late tonight.

[MarkMLl]

I can confirm that I have been testing stuff by moving it between Lazarus 1.6.4 and 2.2.0 on Linux i386 and AMD64 respectively without obvious problems.

I'd note however that that relies on moving a limited number of files around via a Version Control System, which specifically excludes intermediate resources etc. that can be rebuilt.

MarkMLl

[PascalDragon]

I suspect that since I am not using 'Threads', I could remove everything before the 'SysUtils' entry and I can't understand why 'Forms' is in both 

I've just removed 'Forms' from the .LPR file and get the same set of errors. . . .

First of the Forms unit contains the Application variable which is used by the main program file. Second you are aware that a unit (in this case Forms) can be used  from multiple different units? That's the point of them after all...