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

[Samuel Liddicott]

> -----Original Message-----
> From: Jeff Wormsley [mailto:daworm at cdc.net]
> Sent: 20 August 1999 08:14 PM
> To: lazarus at miraclec.com
> Subject: Re: [RE: [Re: [lazarus] wndproc]]
>
>
> On 8/20/99, at 6:52 PM, Michal Bukovjan wrote:
...
> So, how to we bring these totally different approaches to a
> common method suitable for lazarus.

> One, we could limit GTK to the way Windows does things (d&rfc).
> This would mean setting a generic callback for each and every
> callback type internal to Interfaces.pp.  This would take each
> message, wrap it into a standard common format, and then call the
> owners WindProc, where is would be broken back down into its
> original parts, cased, and then call the appropriate handlers if
> any.  Everyone will agree that this is pretty wasteful, but I
> hope you can see where it would make programming lazarus very
> much like programming Delphi, and would allow reuse of a large
> amount of existing code.

make that LARGE ammounts

> Another approach would be to make Windows look like GTK.  This
> approach is what I have been trying unsucessfully to do for three
> weeks now, with little progress.  The problem here is the lack of
> one to one callbacks in Windows.  Everything has to go throught
> WindProc, and especially troubling is the fact that any attempt
> at emulating the GTK way of doing things requires some way to
> store the addresses of the callbacks.  The only good way I have
> found so far is to use SetProp and GetProp to store a handle to
> the object, and then use properties of the object that are
> useless in GTK, or co-opt their function (such as FComponent) to
> a different use.  I am sure these differences in the internals
> would drive the first end user to peer under the hood crazy!

And of course make OS/2 look like GTK.  We don't want to bind too strongly
to any widget manager; and supporting both wndproc AND message handlers
(dispatch is quick) is the only way to support both - and Delphi ALREADY
supports it!  Hooray!

> The thing that is killing Win32 native work right now is not
> having a unique WindProc for each windowed control.  If that were
> the case, then there would be a much smaller case, since then
> only the messages that applied to that control would be present
> in that case statement.  All others fall out the else.

Jeff; I am fighting to have createwnd put back in and CreateParams still
used.  It will work fine for GTK and fine for windows if we do it that way.
It will also be a first experimental stab at being able to claim that
lazarus works supporting two entirely different widget sets.  What I mean is
you will be able to use native windows controls as you want, but use them
the natives delphi:windows way.

Abstractly speaking CreateWnd is "MakeTheWidget" and CreateParams is
"GetTheWidgetImplementationValues" - two functions which have place with
win32 and GTK.  The names are unfortunate for GTK users until there refer to
widgets as WND's and then they are fine.

> But, while putting a WindProc into TComponent or TWinControl
> wouldn't break GTK (No call to CreateWindow, no Hwnd, therefore
> WindProc is never called)

Except I want to change all this with GTK

> it would confuse any application
> developer who was expecting a consistent method of overriding or
> extending the behavior of a control.

Thats true.

> What I am getting at is,  say we have a TEdit control.  This
> TEdit has no facility for having items dragged and dropped onto
> it.  Under Windows, you would intercept the message handler,
> check for a WM_DROP (whatever, memory bad) message, if it was
> found, act on it, otherwise pass control to the default handler.
> In GTK, you would assign a callback.   How does the application
> developer write code to do this that maintains platform
> independence?  With the "make GTK look like Windows" approach, it
> looks like he just replaces checking for WM_xxx messages with
> checking for LM_xxx messages.  How to make it the same process
> for "make Windows look like GTK" I haven't a clue.

> It may be that I have everything all wrong here, or am missing
> some obvious solution.

You are right, and I am with you on this.  I got to know the VCL inside out
when I wrote the form designer, and a wndproc is absolutely essential in
a) making the FCL be similar enough to VCL to be useful
b) is a very good idea anyway - as you say being able to intercept messages
before the message handlers is sometimes the only way to do things.

I suggested that a control have a (secret non-delphi) property call
FSkipWndproc which is false by default.
The GTK handlers could then skip wndproc if this was set to true.
That way the GTK-ites can imagine that they will set this to TRUE everywhere
and we can imagine that we will leave it as FALSE everywhere and then we
don't need to agree!  For sure our code will always work with it turned on
and so will theirs.  If programs seem slow they can try turning it off and
see if it goes much faster (it won't because if there are THAT MANY messages
going round that the usually-mostly empty wndproc makes a difference then
there are a LOT of messages going round - and messages don't go round for no
reason at all they go round because some other action is going on and also
taking up a lot of time).

So....

as you say, we need wndproc.

The gtk-ites could pretend it is merely for intecepting messages before the
handlers in a platform independant way.  I hope the name wndproc won't
bother them too much (they could pretend it is to make the hordes of
converting delphi-ites feel at home).

Sam