There was a discussion in "Custom Drawn" that seemingly should be handled here.

-Michael

There was a discussion in "Custom Drawn" that seemingly should be handled here.

AFAIK many developers add range checking to the IDE build options so many lazarus packages, including the LCL, are tested with range checks.

Mattias

I found that ~/.fpc.cfg seems to acknowledge a "DEBUG" preset and activates several checks when this is found.

Is it possible to do this in the IDE for testing packages ?

-Michael

Mattias Gaertner wrote

AFAIK many developers add range checking to the IDE build options so many lazarus packages, including the LCL, are tested with range checks.

Fine, but various widgetsets have many compiler errors if -CRrt is enabled. Surely these must be fixed, and enabling -CRrt by default will prevent such missages/bugs in future.

eg: Try to compile LCL-GTK2 with -CRrt enabled.

/home/graemeg/devel/lazarus/lcl/interfaces/gtk2/gtk2wsbuttons.pp(237,35) Error: Class or Object types "TCustomBitBtn" and "TWinControlAccess" are not related

LCL-CustomDrawn compiles, but all apps give Segmentation haven't tested LCL-Win32 or LCL-Qt yet.

Regards,
- Graeme -

-CR

does not work by design. The LCL interfaces use classes that intentionally need those typecasts... (not sure if all of them, but certainly some of them)

The details are from before my time, so don't ask me for the details.

Compiler or runtime errors?
Can you point me to the bug reports?

Surely these must be fixed, and enabling -CRrt by default will prevent such missages/bugs in future.

AFAIK -CT is not supported by the LCL.

That's the old style class helper. Not usable with -CT.

LCL-CustomDrawn compiles, but all apps give Segmentation Felipe's answers on custom drawn mailing list. I haven't tested LCL-Win32 or LCL-Qt yet.

Mattias

Add -dDEBUG to the IDE build options.

Mattias

Mattias Gaertner wrote

Add -dDEBUG to the IDE build options.

That sounds easy, but is it really true ?

I understand that the package files are only compiled when necessary. So at least those that are related to a widget type that the IDE itself does not run on, are only compiled with the project, even though they are not compiled when building the IDE (I suppose that is when the "IDE build options" are used), nor seem the compiling of the packages be influenced by the project options (as they are not "project source files". )

-Michael

Since Lazarus requires 2.6.0 anyway one could change that to use normal class helpers:

type
   TWinControlHelper = class helper for TWinControl
     function GetWinControlFlags: TWinControlFlags; inline; // I hope
inline works in that case, if not one might consider it as a bug and
report it :)
   end;
function TWinControlHelper.GetWinControlFlags: TWinControlFlags;
begin
   Result := FWinControlFlags;
end;

And then where TWinControlAccess was used:

if not (wcfInitializing in ABitBtn.GetWinControlFlags) and BuildNeeded then
   ...

Note: The code was not tested, but it *should* work.

Regards,
Sven

Michael Schnell hat am 13. September 2012 um 09:50 geschrieben:

The IDE build options are available via the IDE macro $(IDEBuildOptions). Many packages add this to their custom options. These options are always used - no matter if the package compilation was triggered by the the project or by the IDE.
If you want to add flags to all packages, even those that are not made for this, edit your fpc.cfg. That's the purpose of fpc.cfg.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/dcd6756b/attachment-0001.html>

Sven Barth hat am 13. September 2012 um 10:06
geschrieben:

The IDE needs 2.6.0. The LCL only needs 2.4.2.

[...]

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/7258094e/attachment.html>

But one could already prepare it using ifdefs. This way (if one does it consequently) the LCL could be compiled using -CT at least using 2.6.0+ . :)

Regards,
Sven

I see.

Hopefully the package-testers do know this.

Graeme, what did you experience ?

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/925ffb88/attachment.html>

Sven Barth hat am 13. September 2012 um 11:15
geschrieben:

I meant -CR

Accessing a private variable from outside is a hack. No matter how you do it. I replaced the hack.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/36c5cd9d/attachment.html>

The variable is "protected" otherwise class helpers (or the original hack) wouldn't have worked. And here class helpers are a officially supported method to do this (though one can of course argue whether it was a good decision by CodeGear to allow this or not...).

I replaced the hack.

Also a possibility...

Regards,
Sven

Mattias Gaertner wrote

The IDE needs 2.6.0. The LCL only needs 2.4.2.

So "in the real world" is anybody using Lazarus IDE 0.9.30.x and LCL-only from trunk? I don't think anybody does that. So I think it is safe to keep the two (IDE and LCL) in sync with what FPC version they need.

Regards,
- Graeme -

Michael Schnell wrote

Graeme, what did you experience ?

If I want compiler options to apply across all the code I use (my project, fpGUI, onguard, fptest, tiopf), I switch to MSEide.

Trying to overcome that hurdle with Lazarus Packages is just too much of a pain. MSEide is much simpler in this regard.

And yes, I frequently switch between Lazarus IDE and MSEide. I use the best tool for a specific job.

Regards,
- Graeme -

Graeme Geldenhuys hat am 13. September 2012 um 12:18 geschrieben:

Is this a typo?

I don't think anybody does that. So I think it is safe to keep the two (IDE and LCL) in sync with what FPC version they need.

Due to incompatibilities and new bugs some people can not use a newer fpc, but they can use a newer LCL. For example the android target.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/75861115/attachment.html>

On w32 the IDE still builds with 2.4.4 (at least for me)

Mattias Gaertner wrote

Is this a typo?

No... Old IDE (compiled with say FPC 2.4.4) and newer LCL.

Due to incompatibilities and new bugs some people can not use a newer fpc, but they can use a newer LCL. For example the android target.

Ah, OK. So there are some real use cases for it then.

Regards,
- Graeme -

Graeme Geldenhuys hat am 13. September 2012 um 13:42 geschrieben:

Old IDE with newer LCL is not supported.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/c8cb5afc/attachment.html>

Graeme Geldenhuys wrote

So "in the real world" is anybody using Lazarus IDE 0.9.30.x and LCL-only from trunk? I don't think anybody does that. So I think it is safe to keep the two (IDE and LCL) in sync with what FPC version they need.

You are missing the point of why the LCL supports older FPC versions. It is not for people using the LCL without the IDE. It is for people using platforms which are not supported in FPC 2.6.0

For example Android support is broken in FPC 2.6.x but worked fine in 2.5.x