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

[Shane Miller]

No...that's not the way to do it.

First, I think each control should have it's own.
You keep saying that it's not possible to do because you would need to
assign TControl's windowproc, but that makes it easy!  All you do is during
the create (LM_CREATE) in win32int.pp (or whatever) you  create a callback
procedure that gets passed the Sender.  Then in that callback you do a
TCOntrtol(Data_Received_In_Call_Back).WindowProc or something like that and
you'll be calling THAT control's windowproc.

It should be almost exactly like Delphi's method of handling it......
Because win32int.pp has the SENDER property it CAN call the windowProc.
Another method would be to do a
TObject(Data_Received_In_Call_Back).Dispatch(LM_message)
after determining what message you received in the callback.  That's how we
are doing gtk.  Then the dispatch sends the message and tcontrol or whatever
class that has a
Procedure Something(var msg) message LM_Message;
gets called and handles the message.


------------------------------------------------------------
Shane Miller

Home page : http://www.lakefield.net/~smiller

Auto-IP Publisher : http://www.lakefield.net/~smiller/autoip

Advanced Clipboard : http://www.lakefield.net/~smiller/advclipboard

Lazarus : http://www.pcpros.net/~vbman
----------------------------------------------------------
-----Original Message-----
From: Jeffrey A. Wormsley <daworm at cdc.net>
To: lazarus at miraclec.com <lazarus at miraclec.com>
Date: Tuesday, August 10, 1999 3:52 PM
Subject: Re: [lazarus] More Native Win32 stuff(Pascal,canyouhelphere?)


>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.
>
>_________________________________________________________________
>     To unsubscribe: mail lazarus-request at miraclec.com with
>                "unsubscribe" as the Subject
>    archives at http://www.miraclec.com/list_archives/lazarus
>