Hi Felipe,

I finally managed to squeeze some time to work on Lazarus.

Find here enclosed a svn diff, with my patches. They are:

1) A patch to show the icons for Custom Drawn components on the IDE palette in
/components/customdrawn/customdrawnextra.pas
I took the standard LCL icons, tried to add a CD, but the first attempt was a failure, because once scaled to the proper size, the CD was too thin and very ugly. So for the moment I just used the standard images, while I experiment on different fonts/font size etc, to provide a pleasant image. For the moment, however IMHO standard images are better than the default image for all.
You'll need to put in the same directory (i.e. /components/customdrawn/ )the resource file (enclosed) paletteimg.lrs, which doesn't show in diff, because it's not yet under svn control.

2) A patch in /lcl/buttons.pp to make public a number of constants of TBitBtn which are reused in TCDButton (I checked with Mattias that it can be done without risk)

3) A number of patches in /lcl/customdrawncontrols.pas, to extend TCDButton functionality adding the main features of TBitBtn.

4) A number of patches in /lcl/lazdialogs.pas to implement the class TCDLazMessageDialog, and the functions LazMessageDlg which provide the same functionality of the standard MessageDlg. (There are many overloaded functions, I just implemented the two most common. Others are trivial, and can be added later)

5) Two patches to /lcl/interfaces/customdrawn/customdrawnobject_X11.inc. They're a leftover of the previous patches, which I never sent, It appears. They avoid to send too many useless X11 mouse move and notify events, speeding up things, in presence of fast mouse movements or multiple notify such as in resizing/moving.

In order to test the custom drawn dialogs, and to compare with standard Lazarus Dialogs, I've made a small test program which makes life a bit easier. I can't enclose it, because of its size. You may get it from:

http://www.copeca.it/colla/lazdlgtest.zip

and see if it's worth adding to the examples directory, or not.

Kind regards,

Giuliano

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cddlgs.diff
Type: text/x-patch
Size: 15674 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120910/a662dcab/attachment-0002.bin> -------------- next part --------------
A non-text attachment was scrubbed...
Name: paletteimg.lrs
Type: text/lazarus-resource
Size: 14667 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120910/a662dcab/attachment-0003.bin>

Sounds great.

I just wanted to try this with Lazarus, but the menu to set the Build variables, one of which enables CustomDrawn, seems to have been removed from the project options.

What to do ?

-Michael

They were moved to a new page "IDE macro values".

What to do ?

<click>, <click>

Mattias

Mattias Gaertner wrote

They were moved to a new page "IDE macro values".

Thanks.

Of course this works fine. I think this moving has been a good idea,

Regarding the original topic:

A patch to show the icons for Custom Drawn components on the IDE palette in

I always tried to use the normal "Icons" in the ide "palette" and (as described in the other threads) always failed with this range check errors.

Do I need to use different icons ? I don't seem to find any specific "custom drawn" palette. Do I need to activate it somehow ?

Thanks,
-Michael

Hello,

There seams to be an error in the patch:

=================================================================== --- lcl/lazdialogs.pas (revisione 38609)
+++ lcl/lazdialogs.pas (copia locale)
@@ -1,15 +1,17 @@
unit lazdialogs;

-{$mode delphi}
+{$mode objfpc}{$H+}

 interface

uses

   // RTL

- Classes, SysUtils,
+ Classes, SysUtils, math,

   // LCL
   Forms, ShellCtrls, Buttons, StdCtrls, ExtCtrls, FileCtrl, ComCtrls,

- Dialogs, ButtonPanel, lclstrconsts, FileUtil, Controls;
+ Dialogs, ButtonPanel, LCLStrConsts, FileUtil, Controls,
+ // CustomDrawn
+ customdrawncontrols, customdrawn_common;

==============

The LCL should not depend on the CustomDrawn package from what I understand, I don't even see how this could compile ...

You should not use CD controls in lazdialogs. Just use normal LCL controls. Then when we are using the LCL-CustomDrawn widgetset, the widgetset itself will redirect the controls to be CustomDrawn controls.

I changed TCDStaticText to TStaticText and TCDButton to TBitBtn and commited the patch.

Applied in rev 38612

Felipe Monteiro de Carvalho wrote

Applied in rev 38612

Thanks,

I upgraded to 28612 and made clear and make to the Lazarus IDE.

Then I retried.

I don't see any difference.

What am I supposed to see ?

-Michael

Michael Schnell wrote

What am I supposed to see ?

If you installed the package components/customdrawn/customdrawn.lpk then now they have icons. Although I don't see the CD written on them, that's strange... is it supposed to be like that or an error?

The rest of the stuff will not show immediately, they are structural works.

Felipe Monteiro de Carvalho wrote

You should not use CD controls in lazdialogs. Just use normal LCL controls. Then when we are using the LCL-CustomDrawn widgetset, the widgetset itself will redirect the controls to be CustomDrawn controls.

This is what I did understand and followed.

The situation did not change.

An empty form dopes work (including showing it's header text)

But when I place any visual component (I tested TLabel, TStaticText, TButton, TBitButto, TPanel, TSplitter) I get multiple range errors, staring with one in "tinterp".

-Michael

The patch has nothing to do with your range check errors.

Which operating system/architecture are you using again?

So you are using Linux 64-bits, right? Ok, I have a 64-bits processor here, but I don't remember if I installed 32 or 64-bits Linux ... will check.

Michael Schnell wrote

Do I need to install it to be able to create a Custom Drawn application ?

No. Custom Drawn is available in 2 forms: Via controls which you can place in a form and run in any widgetset and also as a widgetset.

Il 11/09/2012 10:04, Felipe Monteiro de Carvalho ha scritto:

It's most likely a remnant of some tests, which I forgot to remove.

You should not use CD controls in lazdialogs. Just use normal LCL controls. Then when we are using the LCL-CustomDrawn widgetset, the widgetset itself will redirect the controls to be CustomDrawn controls.

Apparently there's been a misunderstanding.
I had understood that lazdialogs had to be considered a Custom Drawn control, and consequently it should use Custom Drawn controls (not Custom Drawn Widgetset, of course).

I changed TCDStaticText to TStaticText and TCDButton to TBitBtn and commited the patch.

However that way I had the opportunity of implementing and testing functionalities of TCDButton, which may become handy in future.

Giuliano

Michael Schnell wrote

On 09/11/2012 11:03 AM, Felipe Monteiro de Carvalho wrote: > So you are using Linux 64-bits, right? No 32 Bit. Sorry that I forget to specify.

Then I fail to see why it doesn't work for you and seams to work for everyone else. Maybe it doesn't work in SuSE only?

I always thought that the problem was in 64-bitness...

Il 11/09/2012 12:42, Giuliano Colla ha scritto:

I checked more carefully:
the CustomDrawn comment was actually a leftover of my tests, because customdrawncontrols and customdrawn_common are not part of the CustomDrawn package, they're apparently part of LCL, by sitting in the /lcl/ directory: that's why it compiles. The CustomDrawn package just installs the components in the IDE, but the components are always there, in a path visible when you use LCL.

To verify it, without applying your patch, but by keeping mine, I removed the CustomDrawn package from my Lazarus IDE, and both lazdialogs and my test program compile and work just fine. The IDE complains about the TCDButton I put in the main form (the IDE doesn't know about it), but it puts it there all the same, and everything works. The only difference is that you don't have Custom Drawn components on the IDE palette.

If that's not desired, then a number of files (such as customdrawncontrols, customdrawn_common, and maybe others, we must check) should be moved from the /lcl/ directory to the /components/customdrawn/ directory, and made part of the Custom Drawn Package (currently they're not). Then Custom Drawn components would be available only when Custom Drawn package is installed.

As of now we have the choice of lazdialogs using standard WS components (as you have done), or Custom Drawn components (as I had done).

The problem maybe will arise when lazdialogs will be used with CD WS: I didn't think about the implications. Did you?

Giuliano

Ah, yes, you are right. But that does not change the fact that lazdialogs should use normal controls, unless they really can't do the job. Because this allows using lazdialogs with native widgetsets with better integration.

Il 11/09/2012 13:47, Felipe Monteiro de Carvalho ha scritto:

Ah, yes, you are right. But that does not change the fact that lazdialogs should use normal controls, unless they really can't do the job. Because this allows using lazdialogs with native widgetsets with better integration.

Well, it's you who lead the dance, and know what lazdialogs was intended for. I just jumped on a running bandwagon!

Any reason to keep Custom Drawn components code in /lcl directory? If there's no reason, I could take care of moving them in the /components/customdrawn directory, and make them part of the Custom Drawn package.

Giuliano

Giuliano Colla wrote

Any reason to keep Custom Drawn components code in /lcl directory?

Otherwise how could LCL-CustomDrawn compile? customdrawncontrols depends on the LCL to work, but LCL-CustomDrawn depends on it to work, so that would be a circular dependency which is not allowed by the lazarus LPK system.

Felipe Monteiro de Carvalho wrote

Then I fail to see why it doesn't work for you and seams to work for everyone else. Maybe it doesn't work in SuSE only?

I can't believe this. I will upgrade to 12.2 some day soon. I'll report back what happens then.

The first range check error is in

TTinterp.pas line 482:

    exc.opcode := exc.Code^[exc.IP];

here exec.IP is 1001

a watch on exc.Code^ says: Len=1001:{64,69, ....

exc.Code^[0] in a watch is 64, exc.Code^[1] in a watch is 69,

Thus exc.Code^ in fact start with element No. 0 and so exc.Code^[1001] rightfully creates a range check error. (In fact the first element to trigger this error, supposedly they are checked one after the other).

I suppose the systems where this works don't have range check enabled. I in fact don't know why in my installation range checking is active, but I feel that such a problem should be cured and not hidden by disabling range checks.

In fact some time ago I provided a patch that cured another (very different) range check error. This also did hit just me, so supposedly noone but me has range checking enabled with these units.

-Michael

I've used OpenSUSE 12.1 for a few months, and a few days ago upgraded (not a reinstall) to 12.2 (64-bit), and OpenSUSE works perfectly for my development work.

What exactly are you trying to test in the CustomDrawn widgetset - I don't normally use LCL, but I don't mind testing something for you under OpenSUSE 64-bit.

in fact don't know why in my installation range checking is active, but I feel that such a problem should be cured and not hidden by disabling range checks.

+1000

I have recently experienced some every strange, and extremely hard to debug code (which contractors wrote for us). GDB had no clue as to where the problem was, and stack traces was useless due to corrupt memory (caused by the bug in our software). It was suggested I enabled range checking for that project, which I did. And within 5 minutes I found the location of the bug and fixed it. I waisted 7 days of debugging before I used the range check function!! Now ALL my projects have range checking enabled.

Range checking is extra help for the developer, and makes doubly sure there isn't some silly code in your project! Don't avoid range checking! If your project fails to build with range checking enabled, you have a problem in your software, which must be fixed.

Regards,
- Graeme -

Graeme Geldenhuys wrote

What exactly are you trying to test in the CustomDrawn widgetset - I don't normally use LCL, but I don't mind testing something for you under OpenSUSE 64-bit.

Great! Just open a new form, drop TButton, TStaticText, TPanel, TGroupBox

Go to the Project Options and select CustomDrawn as the widgetset

Now run the project.

Il 11/09/2012 14:06, Felipe Monteiro de Carvalho ha scritto:

customdrawncontrols depends on the LCL to work, but LCL-CustomDrawn depends on it to work, so that would be a circular dependency which is not allowed by the lazarus LPK system.

Understood.

But now there's a little problem. LazDialog doesn't work properly anymore, at least on Linux (both GTK2 and QT)
The reason is that even with Autosize on, the widget Width property isn't updated immediately.

A message is sent to the WS, the WS does what required, and, in due time sends a message to inform LCL of the new width value. Even calling Application.Process messages isn't enough: we wait for the message being sent to the WS, but not for the message back, which is the one which updates Width.
So if we use too early the Width property to adjust dialog size and button size, we use a wrong value.

Therefore Buttons larger than minimum size (such as Yes to All or No to All) do overlap.
And because of the same reason on Label1, the dialog width isn't adjusted to fit the user message.

The only solution I've found has been to reintroduce the TextExtent function, to compute actual Button and label width. I've also been forced to change from TstaticText to TLabel, because TStaticText apparently doesn't behave properly. Even changing width, it shows only the portion of text which fits in the original width. Weird, but it's so.

I'll test a bit more, and then send you a new patch. Unless you have better ideas.

Giuliano

Graeme Geldenhuys wrote

and a few days ago upgraded (not a reinstall) to 12.2 (64-bit), and OpenSUSE works perfectly for my development work.

Great ! Thanks for the info.

What exactly are you trying to test in the CustomDrawn widgetset -

I just do a very simple test:

- create a new project (just a form)
- change Widget Type to CustomDrawn
- compile
- run -> works nicely.
( - I can easily create an onCreate event for the form and change the caption in there -> works)
- I visually one of said visual component (such as TLabel, TButton, TPanel, you name it)
- compiles
- run -> crash.

I don't normally use LCL, but I don't mind testing something for you under OpenSUSE 64-bit.

In fact I have Suse 32 bit. But I don't suppose that this makes any difference. You can see my Debugging report and the problem is the range of an open array and not of the bit count of a variable.

(I don't intend to use "custom drawn" as it is, but maybe I will want to modify it to allow for creating a completely non-visual <e.g. demonized> "active <i.e. with event-queue>) application, buy just using a homebrew "zero" underpinning instead of X. )

Thanks,
-Michael

I used latest Lazarus Truck and FPC 2.6.0 under 64-bit OpenSUSE. I added the exact components, except TStaticText, was a TLabel from the Standard component palette.

The project compiled fine, but when I ran it I got a Seg Fault, and Lazarus IDE took me to the Assembler window highlighting a 'fpc_do_is' line.

Here is the console output Lazarus IDE generated.

-------------------------
Free Pascal Compiler version 2.6.0 [2011/12/23] for x86_64 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling project1.lpr
Compiling resource
/home/graemeg/devel/tests/customdrawn/test1/lib/x86_64-linux/project1.or Linking project1
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 21 lines compiled, 0.4 sec
2 hint(s) issued
[TCompiler.Compile] end
TMainIDE.DoInitProjectRun
ProgramFilename=/home/graemeg/devel/tests/customdrawn/test1/project1 [TCmdLineDebugger] Debug PID: 6997
[TMainIDE.DoRunProject] Debugger=TGDBMIDebugger
[TMainIDE.DoRunProject] END
TGDBMIDebugger.StartDebugging
WorkingDir="/home/graemeg/devel/tests/customdrawn/test1/"

(lazarus:6883): Gdk-CRITICAL **: IA__gdk_drawable_get_size: assertion `GDK_IS_DRAWABLE (drawable)' failed

-------------------------

Regards,
- Graeme -

Felipe Monteiro de Carvalho wrote

Great! Just open a new form, drop TButton, TStaticText, TPanel, TGroupBox

I tried these components one by one, so see if there is any specific component that causes the : Works and displays : Seg Fault when I try and run the app. TPanel: Seg Fault when I try and run the app.
TGroupBox: Runs, but it doesn't display the then tried to hook up a OnClick event to the TButton. The IDE was fine with that, and the project compiled, but the OnClick event is never fired when I click the button.

In the TButton.OnClick event handler I tried a ShowMessage('ouoeu') call and a WriteLn('aoeu') call, and neither of them was ever reached.

Regards,
- Graeme -

Felipe Monteiro de Carvalho wrote

Great! Just open a new form, drop TButton, TStaticText, TPanel, TGroupBox

In this test I placed only a TPanel on the Form, compiled and ran the application via GDB from the command line. Here is the backtrace.

----------------------
$ gdb ./project1
GNU gdb (GDB) SUSE (7.4.50.20120603-2.1.2)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/graemeg/devel/tests/customdrawn/test1/project1...done. (gdb) break fpc_raiseexception
Breakpoint 1 at 0x43c530
(gdb) run
Starting program: /home/graemeg/devel/tests/customdrawn/test1/project1

Program received signal SIGSEGV, Segmentation fault. 0x000000000043a774 in fpc_do_is ()
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.15-22.6.4.x86_64 libX11-6-debuginfo-1.5.0-2.1.2.x86_64 libXau6-debuginfo-1.0.7-2.1.2.x86_64
libXext6-debuginfo-1.3.1-2.1.2.x86_64 libxcb1-debuginfo-1.8.1-2.1.2.x86_64 (gdb) bt
#0 0x000000000043a774 in fpc_do_is ()
#1 0x00007fffffffcab0 in ?? ()
warning: Range for type <error type> has invalid bounds 0..-128 #2 0x00000000005b5e79 in SELECTOBJECT (this=0x7ffff7f91e30, DC=140737353517760, GDIOBJ=18446744073574714944)
at customdrawn/customdrawnwinapi.inc:5239
#3 0x000000000046eaa7 in DRAWTEXT (this=0x7ffff7f91e30, DC=140737353517760, STR=0x7ffff7fe2d50 'Panel1', COUNT=6, RECT=..., FLAGS=2357) at include/intfbasewinapi.inc:741
#4 0x000000000059da09 in DRAWTEXT (DC=140737353517760, STR=0x7ffff7fe2d50 'Panel1', COUNT=6, RECT=..., FLAGS=2357) at include/winapi.inc:216
#5 0x000000000051bdff in TEXTRECT (this=0x7ffff7f58b80, ARECT=..., X=1, Y=1, TEXT=0x7ffff7fe2d50 'Panel1', STYLE=...)
at include/canvas.inc:1306
#6 0x0000000000678e9c in PAINT (this=0x7ffff7fce4b0) at include/custompanel.inc:133
#7 0x000000000062cad7 in PAINTWINDOW (this=0x7ffff7fce4b0, DC=140737353517760) at include/customcontrol.inc:132 #8 0x000000000060f870 in PAINTHANDLER (this=0x7ffff7fce4b0, THEMESSAGE=...) at include/wincontrol.inc:4758
#9 0x000000000061473f in WMPAINT (this=0x7ffff7fce4b0, MSG=...) at include/wincontrol.inc:6624
#10 0x000000000062ca0d in WMPAINT (this=0x7ffff7fce4b0, MESSAGE=...) at include/customcontrol.inc:112
#11 0x000000000043b4b1 in SYSTEM_TOBJECT_$__DISPATCH$formal ()

#12 0x000000000062c9c8 in ?? ()

#13 0x00007ffff7fce4b0 in ?? ()

#14 0x0000000000000001 in ?? ()

#15 0x000000000000000f in ?? ()
#16 0x00007fffffffd3b0 in ?? ()
#17 0x00007ffff7fce4b0 in ?? ()
#18 0x00007ffff7fe05e0 in ?? ()
#19 0x00007ffff7fa87f0 in ?? ()
#20 0x00007fffffffdb10 in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb)

----------------------

I then enabled -CRrt and -O- fpc compiler parameters. Ran the project again through GDB from the command line, and here it it's backtrace.

---------------------------
$ gdb ./project1
GNU gdb (GDB) SUSE (7.4.50.20120603-2.1.2)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/graemeg/devel/tests/customdrawn/test1/project1...done. (gdb) break fpc_raiseexception
Breakpoint 1 at 0x43c570
(gdb) run
Starting program: /home/graemeg/devel/tests/customdrawn/test1/project1

Program received signal SIGSEGV, Segmentation fault. 0x000000000043a7b4 in fpc_do_is ()
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.15-22.6.4.x86_64 libX11-6-debuginfo-1.5.0-2.1.2.x86_64 libXau6-debuginfo-1.0.7-2.1.2.x86_64
libXext6-debuginfo-1.3.1-2.1.2.x86_64 libxcb1-debuginfo-1.8.1-2.1.2.x86_64 (gdb) bt
#0 0x000000000043a7b4 in fpc_do_is ()
#1 0x00007fffffffcaa0 in ?? ()
warning: Range for type <error type> has invalid bounds 0..-128 #2 0x00000000005b5eb9 in SELECTOBJECT (this=0x7ffff7f91e30, DC=140737353517760, GDIOBJ=18446744073574714944)
at customdrawn/customdrawnwinapi.inc:5239
#3 0x000000000046eae7 in DRAWTEXT (this=0x7ffff7f91e30, DC=140737353517760, STR=0x7ffff7fe2d50 'Panel1', COUNT=6, RECT=..., FLAGS=2357) at include/intfbasewinapi.inc:741
#4 0x000000000059da49 in DRAWTEXT (DC=140737353517760, STR=0x7ffff7fe2d50 'Panel1', COUNT=6, RECT=..., FLAGS=2357) at include/winapi.inc:216
#5 0x000000000051be3f in TEXTRECT (this=0x7ffff7f58b80, ARECT=..., X=1, Y=1, TEXT=0x7ffff7fe2d50 'Panel1', STYLE=...)
at include/canvas.inc:1306
#6 0x0000000000678edc in PAINT (this=0x7ffff7fce4b0) at include/custompanel.inc:133
#7 0x000000000062cb17 in PAINTWINDOW (this=0x7ffff7fce4b0, DC=140737353517760) at include/customcontrol.inc:132 #8 0x000000000060f8b0 in PAINTHANDLER (this=0x7ffff7fce4b0, THEMESSAGE=...) at include/wincontrol.inc:4758
#9 0x000000000061477f in WMPAINT (this=0x7ffff7fce4b0, MSG=...) at include/wincontrol.inc:6624
#10 0x000000000062ca4d in WMPAINT (this=0x7ffff7fce4b0, MESSAGE=...) at include/customcontrol.inc:112
#11 0x000000000043b4f1 in SYSTEM_TOBJECT_$__DISPATCH$formal () #12 0x000000000062ca08 in ?? ()
#13 0x00007ffff7fce4b0 in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x000000000000000f in ?? ()
#16 0x00007fffffffd3a0 in ?? ()
#17 0x00007ffff7fce4b0 in ?? ()
#18 0x00007ffff7fe05e0 in ?? ()
#19 0x00007ffff7fa87f0 in ?? ()
#20 0x00007fffffffdb10 in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb)

---------------------------

I hope all this help.

Regards,
- Graeme -

Graeme Geldenhuys wrote

TButton: Works and displays does it work for you and does not work for me ? Do you really

have RangeCecking activated ? (I have no idea how to (de-)activate this. I never did anything on that behalf and don't know how to do this. But obviously in my installation RangeChecking is activated.

TStaticText: Seg Fault when I try and run the app.

I suppose this is a consequence of not activated RangeChecking. Here I get a range-Check error before it runs into a problem that triggers the SegFault.

TPanel: Seg Fault when I try and run the app.

same

I could not test this but I tested more Form events (Doubleclick, Mouse_xxx). Here I did not get a reaction either.

-Michael

I would hardly call "being able to display it on the screen" as "works". :) So I guess I overemphasised the fact that a TButton simply displays on the screen, but isn't functional.

Yes, range checking was activated. My ~/.fpc.cfg file doesn't have range checking enabled (double check your file - I don't know what is the FPC default in ~/.fpc.cfg), so I have to enable it manually in Lazarus IDE via the "Project Options - Compiler Options - Code Generation" screen. I assume Lazarus IDE passes these settings correctly to the FPC compiler.

While I was at it, I tested LCL-fpGUI too, which I haven't done for a very long time. It seems LCL-fpGUI is at a further working state than LCL-CustomDrawn. The same tests worked (including TButton.OnClick) under LCL-fpGUI, with the exception of the TLabel (which in LCL doesn't have a Window Handle, but in native fpGUI it does).

Regards,
- Graeme -

Graeme Geldenhuys wrote

I assume Lazarus IDE passes these settings correctly to the FPC compiler.

Do you suggest that this is used for the packet libraries, as well ?

I tested forcing a range check on an open array in OnCreate (with GTK2)

Here I don't get a range check error by default, but I can activate range checking in the project options and then I do get the error trap.

Thus I recon that the project option setting only is used for the project source files, not for the packets.

it seems that in ~\.fpc.cfg -Cr is only active if DEBUG is set.

Now don't know if DEBUG is set when the packet is compiled.

OTOH it _is_ obvious that range checking is active here. Otherwise I would not get this error message at all. (And I do feel that Range checking is not active when you compile the UserDrawn package files.)

-Michael

Michael Schnell wrote

Thus I recon that the project option setting only is used for the project source files, not for the packets.

Ah yes, you are right. That is one of the Lazarus IDE drawbacks. Project Options are NOT passed down to Lazarus Packages. So you have to duplicate your Project Options in each Package you use for that project. Apparently there is some Macro trickery you can apply, but all Packages must be modified for this to start working. I once tried this and gave up on it, as it seemed overly complex and felt more like a kludge than a solution.

This is where I like MSEide more. The Project Options is the ONLY options. In terms of MSEide, this means your unit output directory contains a lot more units (everything your project uses), but with the simplicity of compiler/project options being one set of settings. Most developer machines have ample hard drive space anyway, so the large unit output directory is not an ,
- Graeme -

Nice to know that it's not my silliness that hit me here.

In effect we should be happy that this happened to me, and it is obvious that there is a glitch in the code of some package that triggers a range check (if enabled) and triggers a seg fault (if range check is not enabled).

Thus it would be great if the "powers" would be inclined to activate range checking for the compiling of _all_ packets (e.g. via the "DEBUG" setting that is checked in ~/.fpc.cfg, which quite obviously is provided exactly for this purpose, but which I have no idea how to activate. )

-Michael

Michael Schnell wrote

Thus it would be great if the "powers" would be inclined to activate

Please raise this issue in the general Lazarus mailing list. I agree, that range checking should be enabled by default, and only disabled when "release builds" are made by developers.

Really enabling Range Checking options in the LCL packages means that a LCL project can't even be run. This is VERY BAD.

Regards,
- Graeme -