Lazarus design time support broken about graphics32 HOT 21 CLOSED

Hi Melander.

fresh master clone

compiler options for package GR32_DSGN_Lazarus 3.0 -> Test:
... WARNING: The unit search path of "GR32_DSGN_Lazarus 3.0" contains the source directory "/graphics32/Source/Packages/Lazarus/" of package GR32_Lazarus

reorganize + edit packages:
graphics32/Source/Packages/Lazarus/GR32_Lazarus.lpk --> graphics32/Source/Packages/Lazarus/Lib/GR32_Lazarus.lpk
graphics32/Source/Packages/Lazarus/GR32_Lazarus.pas --> graphics32/Source/Packages/Lazarus/Lib/GR32_Lazarus.pas
graphics32/Source/Packages/Lazarus/GR32_DSGN_Lazarus.lpk --> graphics32/Source/Packages/Lazarus/Design/GR32_DSGN_Lazarus.lpk
graphics32/Source/Packages/Lazarus/GR32_DSGN_Lazarus.pas --> graphics32/Source/Packages/Lazarus/Design/GR32_DSGN_Lazarus.pas

GR32_Lazarus.lpk.txt
GR32_DSGN_Lazarus.lpk.txt

compiler options for package GR32_DSGN_Lazarus 3.0 -> Test:
the warning is gone!!

Package GR32_DSGN_Lazarus V3.0 -> Use -> Install ( like yesterday)
-> Warning: Recompiling GR32_Blend, checksum changed for /graphics32/Source/Packages/Lazarus/Lib/x86_64-linux/gtk2/GR32.ppu
GR32_Blend.pas(66,18) Error: Can't find unit GR32_Blend used by GR32

This behavior is known for 12 Years:
see comments an example in https://gitlab.com/freepascal.org/fpc/source/-/issues/19673
(especially inline_circle.zip)

compile GR32_Lazarus.lpk, compile and do not ask again GR32_DSGN_Lazarus.lpk
compile GR32_Lazarus.lpk, compile and do not ask again GR32_DSGN_Lazarus.lpk
install

all Graphics32 Components are shown in component palette

• TBitmap32List, TRangeBar, TGaugeBar, TColorSwatch are placeable and working
• TPaintBox32 -> Error moving component PaintBox32_1:TPaintBox32
• TImage32 -> Error moving component Image32_1:TImage32
• TColorPicker* crashing the IDE

that's all for today

from graphics32.

here it looks like

Error moving component PaintBox32_1:TPaintBox32
... is the shown error message when trying to drag the component into the form

from graphics32.

Hello Anders.
I have just stumbled across the same phenomenon.
I came across the FPC_GTK branch.
After some minor corrections I was able to
open and compile both GR32_Lazarus.lpk and GR32_DSGN_Lazarus.lpk via open package file (*.lpk).
I had previously removed all GR32 remnants by uninstalling and recompiling the IDE.
I also had all the errors you mentioned.
Lazarus IDE v3.2
Hannes

I have just registered and still have to learn how to correct and create branches :-)

my changes:

• /home/hb/Entwicklung/graphics32/graphics32/Source/GR32_Backends_LCL_Gtk.pas

  GR32_Backends_LCL_Gtk.pas (45,12) gtk2, // Brockmann, 20240329
  GR32_Backends_LCL_Gtk.pas (492,16) i:integer; //Brockmann, 20240329
  GR32_Backends_LCL_Gtk.pas (503,52) if (UpdateRegion = PGdkRegion(GDK_NONE)) then // Brockmann, 20240329
  GR32_Backends_LCL_Gtk.pas (516,133) AUpdateRects.Capacity := Max(AUpdateRects.Capacity,AUpdateRects.Capacity, AUpdat...
  

• /home/hb/Entwicklung/graphics32/graphics32/Source/GR32_ColorPicker.pas

  GR32_ColorPicker.pas (63,86) //procedure WMEraseBkgnd(var Message: TWmEraseBkgnd); message WM_ERASEBKGND;  //...
  GR32_ColorPicker.pas (64,86) {$IFDEF FPC}                                                                    ...
  GR32_ColorPicker.pas (65,86) procedure WMEraseBkgnd(var Message: TLMEraseBkgnd); message LM_ERASEBKGND;    //...
  GR32_ColorPicker.pas (66,86) {$ELSE}                                                                         ...
  GR32_ColorPicker.pas (67,86) procedure WMEraseBkgnd(var Message: TWmEraseBkgnd); message WM_ERASEBKGND;    //...
  GR32_ColorPicker.pas (68,86) {$ENDIF}                                                                        ...
  GR32_ColorPicker.pas (734,119) procedure TScreenColorPickerForm.WMEraseBkgnd(var Message: {$IFDEF FPC}TLmEraseB...
  GR32_ColorPicker.pas (735,119) begin                                                                           ...
  GR32_ColorPicker.pas (736,119) Message.Result := 1;                                                            ...
  GR32_ColorPicker.pas (737,119) end;                                                                            ...
  GR32_ColorPicker.pas (738,119) {                                                                               ...
  GR32_ColorPicker.pas (739,119) procedure TScreenColorPickerForm.WMEraseBkgnd(var Message: TWmEraseBkgnd);      ...
  GR32_ColorPicker.pas (740,119) begin                                                                           ...
  GR32_ColorPicker.pas (741,119) // Do not erase window background                                               ...
  GR32_ColorPicker.pas (742,119) Message.Result := 1;                                                            ...
  GR32_ColorPicker.pas (743,119) // Brockmann, 20240329
  GR32_ColorPicker.pas (744,119) // Note: Does not work with FPC. The message is processed but the background is ...
  GR32_ColorPicker.pas (745,119) end;                                                                            ...
  GR32_ColorPicker.pas (746,119) }                                                                               ...
  

• /home/hb/Entwicklung/graphics32/graphics32/Source/GR32.ImageFormats.PNG32.pas

  GR32.ImageFormats.PNG32.pas (45,17) GR32_Png,  // Brockmann, 20240329
  

• /home/hb/Entwicklung/graphics32/graphics32/Source/GR32.ImageFormats.TPicture.pas

  GR32.ImageFormats.TPicture.pas (45,62) {$ifndef FPC} Windows, {$else FPC} LCLType, {$endif FPC}  // Brockmann, 20240329
  

from graphics32.

@HannesBrockmann Thanks.
I'll give it a try but I think your changes have more to do with #270 than the problem in this issue; I can't see how your changes would prevent the "checksum changed" problem.
It's more likely that the FPC_GTK branch hasn't got the problem at all because the Graphics32 changes that causes it was introduced after that branch was created.

from graphics32.

@HannesBrockmann Using the FPC_GTK branch I initially got the exact same error (checksum changed) but after adding the -Ur compiler option to the design time package and 3-4 recompiles I finally managed to get it installed.

I have integrated most of your changes but obviously I can't test if they work. You should be able to test if it works with the Sprites and GradLines examples.

I have a few questions:

• GR32_Backends_LCL_Gtk.pas (45,12) gtk2, // Brockmann, 20240329
  I don't understand where this is supposed to go. The {$IFDEF LCLGtk2} section already has it, so is it in the {$ELSE} section?

• GR32_Backends_LCL_Gtk.pas (516,133) AUpdateRects.Capacity := Max(AUpdateRects.Capacity,AUpdateRects.Capacity, AUpdat...
  I don't understand this line. Something appears to be missing.

• procedure TScreenColorPickerForm.WMEraseBkgnd
  I'm not sure what you change means (other than the different message constant). Are you saying that the LM_ERASEBKGND handling works - contrary to what my comment stated?

• GR32.ImageFormats.PNG32.pas (45,17) GR32_Png, // Brockmann, 20240329
  Is FPC case sensitive with regard to the unit names?

• GR32.ImageFormats.TPicture.pas (45,62) {$ifndef FPC} Windows, {$else FPC} LCLType, {$endif FPC} // Brockmann, 20240329
  Shouldn't this just be {$ifdef FPC} LCLType, {$endif FPC}? As far as I can tell the unit doesn't need the Windows` unit with Delphi.

I have just registered and still have to learn how to correct and create branches :-)

The easiest way is:

1. Fork the repository in Github:
   
2. Clone your fork to your local system.
3. Create a local branch and make the changes.
4. Commit and push your branch to your fork on Github.
5. Create a pull request from your fork's Github page.

from graphics32.

The Graphics32 component glyphs in Lazarus are gone for now as I can't figure out to get Lazarus to use the .dcr file.

from graphics32.

feedback Latest master + Lazarus: Version 3.2, FPC 3.2.2, x86_64-linux-gtk2

So far I have been working with the latest version of the FPC_GTK branch.
Now that the branches have been merged I have just tried to compile the current master branch:

How I managed to install GR32_DSGN_Lazarus 3.0

(1) make sure, there is nothing old left
config_lazarus/packagefiles.xml -> delete ...

(2) fresh master branch clone
git clone https://github.com/graphics32/graphics32

(3) Package -> Open Package File (*.lpk) GR32_DSGN_Lazarus.lpk
(4) Package -> Open Package File (*.lpk) GR32_Lazarus.lpk

(5) compilation

1.try

• Compile GR32_Lazarus.lpk --> (compiles with no errors)
• Compile and do not ask again GR32_DSGN_Lazarus.lpk
  ( compiles with error: (--> the old known #297 ) ...
  Warning: Recompiling GR32_Blend, checksum changed for ./Lib/x86_64-linux/gtk2/GR32.ppu
  GR32_Blend.pas(66,18) Error: Can't find unit GR32_Blend used by GR32)

2. try

• Compile GR32_Lazarus.lpk --> (compiles with no errors)
• Compile and do not ask again GR32_DSGN_Lazarus.lpk
  ( compiles with error: (--> the old known #297 ) ...
  Warning: Recompiling GR32_Blend, checksum changed for ./Lib/x86_64-linux/gtk2/GR32.ppu
  GR32_Blend.pas(66,18) Error: Can't find unit GR32_Blend used by GR32)

3.try

• Compile GR32_Lazarus.lpk --> (compiles with no errors)
• Compile and do not ask again GR32_DSGN_Lazarus.lpk --> ( compiles with no errors )

A miracle - don't ask me why this is so

(6) installation

Use Install GR32_DSGN_Lazarus.lpk
Installing the package GR32_DSGN_Lazarus 3.0 will automatically install the packages: GR32_Lazarus 3.0

The package "GR32_DSGN_Lazarus 3.0" was marked for installation.
Currently Lazarus only supports static linked packages. The real installation needs rebuilding and restarting of Lazarus.
Do you want to rebuild Lazarus now?

Lazarus compiles with no errors, Graphics32 V3.0 is installed

In my project ( with the Designtime components of the previous version ) the form is only displayed as text,
but can be compiled.

... However, the application itself then crashes in GR32_LowLevel.pas crashes

Lazarus design time support is not completely broken after all ...
However, I was able to compile and install the latest version of the FPC_GTK branch without any errors.
I think #297 is due to the constellation
GR32 - GR32_System - GR32_Bindings - GR32_Blend, which somehow all need each other :-)

GR32          interface      uses GR32_Bindings;
              implementation uses GR32_Blend,...
      
GR32_Blend    interface      uses GR32,GR32_Bindings;
              implementation uses GR32_System,...    
     
GR32_Bindings interface      uses GR32_System

from graphics32.

A miracle - don't ask me why this is so

Yes. Throw in a couple of internal errors and it mirrors my experience.
I think what made it build in the revision we have now was that I reverted some of the inline declarations. However I occasionally got to build before that too. Oh well.

However, the application itself then crashes in GR32_LowLevel.pas crashes

Please create an issue if you want me to look at it.

from graphics32.

all Graphics32 Components are shown in component palette

This is what I get:

So all the component glyphs are gone.

TPaintBox32 -> Error moving component PaintBox32_1:TPaintBox32
TImage32 -> Error moving component Image32_1:TImage32

Works for me. What do you mean by "moving component"?

TColorPicker* crashing the IDE

Reproduced.

Additionally TColorPickerGTK has some visual bugs.

I am currently in the process of rewriting parts of TImage32/TImgView32. Specifically I have replaced the internal TRangeBars and replaced them with the standard TScrollBar. The end goal is to be able to support Delphi's FireMonkey framework (#101). I already support the non-visual part (e.g. TBitmap32, etc) but I'd like to also have support for TImage32/TPaintBox32, etc.

from graphics32.

I figured it out: I had to specify the explicit resource name in the source ({$R 'GR32.Design.Reg.dcr'}) instead of {-$R *.dcr}.

I have reproduced the crashes you experienced with the "Color Picker" example project. Investigating now.

from graphics32.

To get closer to the #297 error, I changed the project structure as a test:

When compiling GR32_DSGN_Lazarus.lpk, an already compiled GR32_Lazarur.lpk is searched for.
If this does not yet exist, it is compiled, whereby all units required for this are included via uses and inline.
All compilates assigned to this compiler run receive a checksum.
The GR32_DSGN_Lazarus.lpk is now compiled in the next compiler run.
Now, however, the required units have a checksum that does not belong to this compilation run and must therefore be compiled again. (regardless of whether they are included via the interface section or the implementation section.
The same happens when Lazarus is recompiled afterwards for the actual installation.
This is the next compilation run with new checksums.

I have therefore removed the GR32_Lazarus.lpk from GR32_DSGN_Lazarus.lpk and added the 44 units from GR32_Lazarus.lpk directly to GR32_DSGN_Lazarus.lpk.
This makes the directory structure flatter, but above all there is only one compiler run.
voila - GR32_DSGN_Lazarus.lpk is stand-alone compiled without any problems.

But when installing, a new compiler run is started and of course the checksums are no longer correct.
I thought that the compiler option -Ur in GR32_DSGN_Lazarus.lpk forbids recompiling (I'll have a look at this tonight).

graphis32/Source/
graphis32/Source/Design/
grahics32/Source/Packages/Lazarus/GR32_DSGN_Lazarus.lpk,GR32_DSGN_Lazarus.pas

from graphics32.

Here's what I'm seeing with the current setup:

1. Delete Packages\Lazarus\Lib and Packages\Lazarus\Design (so I don't have to "Recompile Clean" instead of just a "Compile").
2. Compile GR32_Lazarus; Compiles everything. No problems.
3. Install GR32_DSGN_Lazarus; Checksum changed.
4. Compile GR32_Lazarus; Compiles a bunch of files. No problems.
5. Install GR32_DSGN_Lazarus; Checksum changed.
6. Compile GR32_Lazarus; Compiles 3 files. No problems.
7. Install GR32_DSGN_Lazarus; Compiles a bunch of design-time files. Recompiles and links Lazarus. No problems.

This sucks but given that we're up against Checksum changed I think that it's close to as good as it gets without completely mangling the packages.

Apart from the above, all the design-time errors should have been fixed now. If you are still experiencing problems when dropping component/controls on forms, please let me know.

from graphics32.

The last constellation I tried (see last post) runs with

More -> Compile,
More -> Recompile Clean
More -> Recompile All Requiered

completely without errors.

When recompiling the IDE, GR32_Blend is not found again.

The following is interesting:
the generated state-files gr32_dsgn_lazarus.compiled are identical in both cases.

I have no idea what is different when copying the IDE.
Which compiler flags and paths are used for compilation?
( Surely it shouldn't be the ones under project options?
or the ones from fpc.cfg? )

According to wiki, everything is actually as it should be.

I will test your current status right away.

By the way - when (exactly after which change) did #297 appear for the first time?

from graphics32.

By the way - when (exactly after which change) did #297 appear for the first time?

I have no idea. For me it surfaced when I upgraded to Lazarus 3.2 (FPC 3.2.2). Before that I was on Lazarus 2.2.6 (FPC 3.2.2) so that's a bit strange.

from graphics32.

PaintBox

Image

Component, RGBA, CSV

HSV & GTK -> empty MessageBox


That doesn't necessarily mean much.
Who knows what kind of bugs you can get into with this kind of "installation".
Can the whole thing still be compared with the FPC_GTK branch?
Everything worked there, except for the glyphs of the ColorPicker.

Which Lazarus, FPC versions do you work with?
I use
Verbose: Free Pascal Compiler version 3.2.2-r0d122c49 [2024/03/29] for x86_64

from graphics32.

That doesn't necessarily mean much.
Who knows what kind of bugs you can get into with this kind of "installation".

I think it's a problem. You can probably reproduce the problems at run-time if you try to compile/run some of the examples that use these controls.

Can the whole thing still be compared with the FPC_GTK branch?

Sure it can be compared but there's a massive amount of changes. Git bisect would probably be the easiest way to identify when the problem was introduced.

Which Lazarus, FPC versions do you work with?

Lazarus 3.2 (rev lazarus_3_2) FPC 3.2.2 x86_64-win64-win32/win64

from graphics32.

Well, what good is it?
In computer science, there is only 0 or 1.
The basis should be right, otherwise you never know where you stand. Let's find the error.

from graphics32.

Hi Melander.
Here comes some evening reading
GR32_installation_process.pdf

from graphics32.

Admirable effort but I think it's a wild-goose chase.

As I understand it the checksum changed, unit not found error is caused by the way FPC implements inlining - or rather how it treats a failure to inline. Delphi has much the same restrictions on what can be inlined, due to it being a one-pass compiler, but in Delphi, if the compiler determines that a function call can't be inlined due to dependencies and compilation order, it just doesn't inline those calls and move on. FPC on the other hand tries to be clever and circumvent the restrictions by doing a second pass compile on an already compiled unit and in that attempt shoots itself in the foot and bugs out with checksum changed. It's an entirely preventable problem (see Delphi) but apparently they have decided that it's not important.

In my opinion this problem is solely caused by a deficiency of FPC and it should be fixed in FPC. Unfortunately the FPC developers appears very reluctant to own this problem and admit that they have made a mistake in the design of FPC's inlining so while I have no doubt that it will eventually be fixed it's unlikely to be anytime soon. Making some noise on the Lazarus forums would probably help.

So you're welcome to keep going at this problem but my stance is that it works good enough for me (I'm not actually using Lazarus/FPC for anything other than keeping Graphics32 compatible) and I'm not going to make substantial changes to the source in order to work around the problem.

from graphics32.

Hi, yes
My main concern here is to understand what is happening.

In no way about tinkering with the source code.

I have used GR32 (since its very first version) for many projects and have developed many useful components based on GR32 that I would like to make usable in Linux.

If the inlining actually behaves as assumed, then the error should have disappeared if the inlining is completely excluded by defines (as already implemented above) .

{$IFDEF USEINLINING} inline; {$ENDIF},
{$IFDEF PUREPASCAL} inline; {$ENDIF},
{$IFDEF INLININGSUPPORTED} {$DEFINE USEINLINING} {$ENDIF} 

Unless FPC itself tries to inline parts for which this was not intended.
Of course, this would slow everything down, but the error should be gone.
There should then be no reason to recompile an already successfully created ppu - after it can be successfully found and published as can be seen.
Starting from this state, the inlines can be switched on again step by step

from graphics32.

Well: Without further ado, I used find in files + replace to completely remove the inlines from all source files:

{$IFDEF USEINLINING} inline; {$ENDIF}               --> {Brockmann1}
{$IFDEF PUREPASCAL} inline; {$ENDIF}                --> {Brockmann2}
{$IFDEF INLINING} inline; {$ENDIF}                  --> {Brockmann3}
{$IFDEF USEINLINING}inline;{$ENDIF}                 --> {Brockmann4}
{$IFDEF INLINE} inline; {$ENDIF}                    --> {Brockmann5}
{$IFDEF USENATIVECODE} inline; {$ENDIF}             --> {Brockmann6}
{$IFDEF INLINING_ENHANCED_RECORDS} inline; {$ENDIF} --> {Brockmann7}
inline;                                             --> {Brockmann8}

When compiling, the same happens as before:

• Standalone compilation runs without errors
• IDE compilation ends with
  GR32_Blend.pas(85,12) Error: Can't find unit GR32_Blend used by GR32

This means: it is not due to the inlines

from graphics32.