[lazarus] Free IDE?

[Samuel Liddicott]

> -----Original Message-----
> From: Michael A. Hess [mailto:mhess at miraclec.com]
> Sent: Thursday, September 30, 1999 11:58 AM
> To: lazarus at miraclec.com
> Subject: Re: [lazarus] Free IDE?
>
>
> Samuel Liddicott wrote:
> >
> > Because Michael Hess is dead set against it.
>
> Hooooold on!
>
> I am not dead set against windproc. I am against making any of the code
> WIN32 specific or following a WIN32 design.

Being win32 specific is different to following win32 design.
I am against being win32 specific, but there is nothing wrong with that
design.

> If you can add windproc
> without the need of ifdefs and the like to implement it then fine by me.

yep

> I just don't want to see alot of ifdef stuff being added so that the
> code will work in a pure WIN32 invironment when we already have lots of
> tools for doing that already.

fine

> If the windproc stuff can be added to the
> base Lazarus classes so that it can be used with a Windows API set well
> then fine.

yep, thats what I want.

> However, unless I misunderstood something you wanted to add
> WindProc to work with GTK. Isn't that right?

Well its either that, or use IFDEF's which you are dead against.

> Since that isn't how GTK
> does the message handling I don't see how you could add doing it using
> the windproc method that Delphi uses without tying the LCL directly to
> GTK. If you can show me how, by all means do it.

instead of calling Dispatch, call WndProc and let DefaultWndProc call
dispatch.  Just like Delphi.
We discussed this but you didn't like it because of the perceived overheads
in message handling.

My answer was that:
a) its no issue if there are only a few messages
b) if there are a lot of messages then a lot of something else is going on
too which is probably tkaing up even more time, so no-one will know.
c) introduce FSkipWndProc into TControl which could be set to TRUE in all
controls that don't need wndproc (which would be none of the ones I would
use) as a method of postponing the fight till runtime when its hard to tell
who won.

any other way requires IFDEF's which
a) we don't want
and
b) won't solve the problem.
We need wndproc in ports of lazarus.

> > >We have been drawn down
> > >in to discussions of WindProc, WinHandles, etc. etc. and it
> just doesn't
> > >need to be talked about or done at this time.
> >
> > Basically he wants to tie strongly with GTK to get the themes, DnD and
> > Corbra for free (despite the fact it goes against his other well
> > publicised intention to keep things platform independant).
>
> Here is where you are mistaken. Not PLATFORM independant, WIDGET (API)
> independent. This is refering to GTK, Qt, wxWindows, XForms, XLib, etc.
> etc. etc.

Wndproc gives us widget indepedance.  No wndproc ties us to GTK, AND ties us
OUT of the Delphi component model.

> In many cases such as GTK, wxWindows this widget sets already have a
> Windows (WIN32) version which means they would also be platform
> independant if they adhere to these widget sets.

So... you don't really want widget set independance then?  No matter.  Even
under GTK, wndproc is needed, as mentioned it is the ONLY way to intercept
messages to a control.

> Again maybe I am missing something here. Please show me again how, in
> code if possible, how you could do this and not tie directly to the
> widget API.

let wndproc dispatch.

> We can take it off of the mailing list to discuss. Just email me
> directly.

Well I'm happy to let it go now borland have started on their linux tool.
What I've said is plain, if it diverges from the current road map I am happy
to leave it, but to work, I need it.

Sam