[RE: [Re: [lazarus] wndproc]]

[Michal Bukovjan]

"Samuel Liddicott" <sam at campbellsci.co.uk> wrote:

> > I am not sure about the single WndProc either. This approach
> > certainly slows
> > things down, and I find the GTK (multiple signals) way more versatile.
> 
> > I think we will have to decide if we want
> > 1) Lazarus to be Delphi compatible to the point that it is bound
> > to Windows.
> 
> I don't know what you mean "bound to windows".  How about "can be bound to
> windows"?  But the only reason I'm interested in Lazarus is because it
might
> compile Delphi source code with little change.  The claim on the web site
is
> that we are porting Delphi to linux because Borland won't.  We even have
the
> penguin wearing the Delphi wig.  If we are only interested in superficial
> compatability, why even bother with that?

We are interested (as I understand it) in the possibility to have Lazarus for
both Win32 and Linux, and use any arbitrary widget for visuals.

This means that we should avoid all Win32 stuff in core components like
TComponent, TControl, TWinControl, and the basic set of controls, so that it
is possible to write an application (using standard components) once and
compile under Win32 and Linux without no code change.

I say SHOULD, but if neccessary, we may opt to insert some Win32 specific code
and let it become dummy under anything else.

There was a discussion on that topic recently, including whether we should use
IFDEFs and such, which resulted in those gtkint.pp, win32int.pp units and all
this stuff.

So I think the possibility to use existing Delphi components descendants that
work and use Win32 specific stuff (i.e. Windows messages) will be, ..er..,
somewhat limited to Windows, and useless under Linux.

While this may be valid from Windows point of view (the application will not
be portable, author decides), if such thing would be found in core components,
that would handicap other widget platforms. And the other way around, we could
certainly use some GTK specific stuff in core components, the other, including
Win32 users, would be handicapped instead. Not speaking about Motif/Lesstif,
Qt, or whatever.

Stop. I am not a moron :-) I am not the one who decides about this in the end,
anyway (that is the core component maintainer). That is just my point of view.
And since you seem to know the Win32 widgets stuff well, it may be inevitable
to have some Win32 support integrated after all, if you say so, be it by
IFDEFs. IMHO, that is the solution Sibyl chose, as I looked into their code.

> 
> > 2) Leave out some Delphi solutions which had to be created/were suited
for
> > Windows, and supply our own, more versatile ones (be their
> > Delphi-incompatible).
> 
> Ho ho.  Don't forget we want to bind to more GUI's that GTK. OS/2 is also
> very win-like with a wndproc.  We get speed OR flexibility.
Ok, ok :-)

> 
> > Again, remember that Delphi is VERY designed for
> > Windows, and if we want Lazarus for as much platforms as possible, we
> > definitely will need to abandon some Delphi approaches.
> 
> If we want Lazarus for as much platforms as possible, we definitely do not
> need to rule out platform approaches.

??? What do you mean ?

> 
> > The shiny example of the 2) is Handle, which is rarely found
> > anywhere beyond
> > Windows, and since Windows get COMized, not even there in the future (my
> > guess).
> 
> The handle is "some" reference to the "real" object that is managed by the
> bound GTK.  This is going to be used with whatever gui we bind to.  OK,
> handle isn't the best name UNDER GTK but its a better name under some
others
> (like Win or OS2).
Yes. But while it is an integer under Win32 (32-bit), it is meant to be a
pointer under GTK (which happens to be 32-bit on IA32). Then, I am not sure
about 64bit platforms. (The compiler might take care about that, though).

> 
> The only reason for thinking a .wndproc slows things down is if you think
> what's in the wndproc isn't needed - and yes its faster if you do less.
> Wndprocs *are*
> 
> a) A primary place to intercept and *modify* ALL messages to a component
> before the dispatch
> b) A place to intercept messages whose message number is not known at
design
> time
> 
> There are a lot of *components* out there that rely on this mechanism!
> Honest!  Few applications use it, but MANY components do.

You are absolutely right on this one. Still I claim that the HUGE case
statement is NOT effective. In my opinion, it is not the best approach,
although it is usable.

It is true that many components DO use it, as they have no other choice under
Windows, anyway (or do they?).

> 
> We need support from existing Delphi components to make Lazarus more useful
> quickly.  We don't want much (if any) work involved in porting over
> components.
> 
> If you like, let each component have a flag which says whether or not
> wndproc can be skipped. The GTK callback handler could check this flag and
> only call wndproc if it is not set.

Hmm, that could be a viable solution :-)

> 
> But the fact is, wndproc ONLY slows things down to any degree if there is a
> lot in it - in which case it is obviously important; OR because there are a
> lot of messages going round - in which case the computer must be quite busy
> doing something so quite naturally the user expects it to take much more
> time than the wndproc overhead is going to add.
> 
> Trust me, we NEED .wndproc - HEY the delphi form designer "requires"
> .wndproc so it can intercept the paint messages to the form and paint the
> grid.  The ability to intercept the wndproc of another component is also
> VERY COMMONLY USED.  So we can't even presume that the primary .wndproc for
> a control is control.wndproc - but we can implement this later.

Now, as I remember, intercepting owner's or parent's WndProc (I know that
trick) is generally considered a dirty hack and should be used with great
care. Again, the form designer in Lazarus may use a completely different
approach, since it has to be Linux-compatible. In Linux, there is no Win32 API
to intercept any WndProc !

Enough. Just once again - if the WndProc is really inevitable, it may be
there, after all. But we should double-check the need for any OS
platform-specific code.

Have fun,

Michal Bukovjan


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.