[lazarus] Win32 Interface

[Mattias Gaertner]

On Mon, 23 Jun 2003 12:22:46 +0200
"Marc Weustink" <marc.weustink at cuperus.nl> wrote:

> + From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
> + Sent: maandag 23 juni 2003 12:07
> +
> + On Mon, 23 Jun 2003 00:06:56 +0200
> + Marc Weustink <marc at dommelstein.net> wrote:
> +
> + > [snip]
> + > Ehm... can you give an example where the debugger doesn't stop ?
> +
> + Whatever you did with your last update, the endless loop is gone and so
> is+ the endless loop of the debugged lazarus also. Now the compiler
> + stops on the range check error.
> 
> I'm not aware of such a change last week.
> 
> + But without a valid error line. The callstack says the
> + same: debugmanager line 1698. The range check error happens
> + somewhere in the debugger initialization.
> 
> ???
> 
> In the sample I gave it shows the correct line. If even the callstack
> gives it then I don't know what's going on. (On exception handling I
> retrieve the exception line separate form the call stack)
> 
> + The sad thing is, that the debugged IDE still shows
> + its splash screen, which hides any message dialog and this makes your X
> + unusable.
> 
> :-)
> 
> + So, I have improved a few things:
> + - the lcl now sets its own exception handler earlier
> + (Application.Initialize)
> + - the lcl now hides all forms with FormStyle=fsStayOnTop, before
> + showing the error message
> 
> It would have been no problem if messagedialogs were shown on top of
> fsStayOnTop.

gtk has no fsStayOnTop in the sense of win32. It has transient windows and
toolwindows. Transient windows stay on top of another window and toolwindows
stay on top of everything. The only solution to put a message dialog on top
of a toolwindow aka SplashScreen is to hide the toolwindow.

 
> + - I added a --no-splash-screen option to the command line options
> + of the IDE
> +
> + Now we can start fixing the range check errors. First one is:
> debugger.pp+ 2900.
> 
> I always found those range checks and such to strict (or better, not
> practical), but whats wrong with:
>    Result := TBaseException(inherited Add);

Good question.


Mattias