[lazarus] More Native Win32 stuff(Pascal,canyouhelphere?)

[Jeffrey A. Wormsley]

On 8/10/99, at 11:44 PM, Marc Weustink wrote: 

>You can pass extra info to a Windows window. This way you could store the
>"self" value when you create it. When you receive a Windows message you
can
>retrieve the "self" value for this HWND. Look at GetProp, SetProc
>(user32.lib, windows.h) etc.

The point was, at the time of LM_Create, I didn't think I had a windows
procedure.  What Michael is suggesting is that I have one and only one, and
it does the job for every component, and hence has to know (via a TList)
about each and every component.  This is completely different from Delphi,
in that Delphi has a single window procedure for every component, and that
window procedure only need to know about itself.  The confusion is the
definition of "Window Procedure".  I am using it to mean the procedure that
is associated in Windows to the HWnd handle (I will refer to this in "'s).
So that if windows detects a window handle that needs a message, it calls
the "window procedure" associated with that handle.  In Delphi, this is a
trivial process, since the "window procedure" associated to the handle is
on a one on one basis, each Hwnd handle only has its own "window procedure"
that messages can be passed to.

Going the way Michael has suggested would mean that every Hwnd is
associated with one single "window procedure" and that procedure would be
responsible for looking up the Hwnd in a list, retrieving the Data pointer
that was passed in the LM_CREATE SendMessage, and then using the Dispatch
method of the TObject pointed to by the Data pointer to send the
apporopriate message to the component for processing by the attached
message handler, if present.  Dispatch is calling the LCL [window
procedure] (brackets as opposed to "'s), or message handler if you will,
that searches up the component tree trying to find a handler for the
message.  

This is feasible, but I am not convinced it is the best way to do things.
For one, it would be a real bottleneck in terms of performance.  Having to
look up in a list of hundreds or thousands of components would seem to be a
needless slowdown, as compared to having a unique "window procedure" for
each component.

When I started this, I was hoping to do it the Delphi way, where each
window handle had it's own "window procedure" as a method of the TControl
object, but there is no way I can see at the Interface.pp level, that I can
see, to do this.  It has to be done at the TControl level, but TControl is
in the LCL, and hence should ideally be API toolkit independent.  The quick
and dirty fix would be to make the TControl use IFDEFs to check for windows
and compile in the "window procedure" code, and let that procedure take the
WM_xxx messages and Dispatch the LM_xxx equivalents.  It isn't clear how to
go the other way, though.  In other words, how does a form, on recieving a
LM_RESIZE send a LM_RESIZE to all of it's children.  My guess is that it
can bypass the "window procedure" completely and just Dispatch the
LM_RESIZE to each of the children directly.

I think I have most of the confusion cleared up now, and can now
concentrate on how best to implement whichever mechanism is deemed best.

Jeff.