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

Marc Weustink weus at quicknet.nl
Wed Aug 11 15:43:27 EDT 1999


At 18:32 10-08-99 -0400, "Jeffrey A. Wormsley" <daworm at cdc.net>
 wrote:
>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.

Correct.

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

Retrieving that datapointer is the only "overhead" here, but not a big
issue if you want to have a certian platform independency.

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

Thats more or less the same delphi does, only in stead of one dispatch
method, they use an overridable winproc method which finally calls the
dispatch method

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

I dont think getting your data by a GetProp will be a bottleneck. Delphi
itself uses it to check if a window is a delphi window.

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

AFAIK Delphi does not send a resize message to its children. 

Marc







More information about the Lazarus mailing list