[Re: [lazarus] wndproc]

[Samuel Liddicott]

> -----Original Message-----
> From: Michal Bukovjan [mailto:mbukovjan at netscape.net]
> Sent: 17 August 1999 12:36 PM
> To: lazarus at miraclec.com
> Subject: Re: [Re: [lazarus] wndproc]
>
> 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?

> 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.

> 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.

> 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).

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.

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.

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.

Sam