Where is AllocateHwnd?

[Guest]

I use AllocateHwnd in order to get a window handle to pass windows messages in a lot of my components, but I can't find this function in the classes unit.
  I don't care about cross platform compliance at this point.

[Marc]

What's wrong with TWincontrol.Handle ?

[Anonymous]

I need this method also. I need a invisible window to receive message and use my custom WindProc to process my custom-defined messages, if I use TWinControl.Handle, I must create a new class inherits from TWinControl, then override WndProc()method, that's need much more work.

So I still think methods like AllocateHwnd() and DeallocateHwnd() are needed!

[Phil H.]

I need this method also. I need a invisible window to receive message and use my custom WindProc to process my custom-defined messages, if I use TWinControl.Handle, I must create a new class inherits from TWinControl, then override WndProc()method, that's need much more work.

So I still think methods like AllocateHwnd() and DeallocateHwnd() are needed!

Yes, they are needed. I posted this as bug 4249 on 2005-08-03 with FPC since in Delphi these functions are part of the Classes unit, which appears to be FPC's responsibility, not LCL's.

For now, what I'm doing is just using the AllocateHWnd/DeallocateHWnd code from Delphi 7's Classes.pas in porting my components. I hope that in time they become available cross-platform in FPC's Classes unit.

[mattias]

I took a look at the Delphi implmentation and it looks very winapi specific.
Can you tell, define in a platform independent way, what AllocateHwnd does?
Then maybe non windows people can help to implement it. And if it is possible on all platforms it will be added to the LCL.

[Marc]

AllocateHwnd is a Delphi "utility" for the windows way of IPC.
External apps and sometimes also in one app, one needs a Window to send messages to.
Since IMO this way of communication is primarly defined by those external apps, there is IMO no way to make such generic and platform independent and usefull at the same time.

[Phil H.]

AllocateHwnd is a Delphi "utility" for the windows way of IPC.
External apps and sometimes also in one app, one needs a Window to send messages to.
Since IMO this way of communication is primarly defined by those external apps, there is IMO no way to make such generic and platform independent and usefull at the same time.

Both Delphi's TTimer control and Orpheus' TOvcTimer controls use AllocateHWnd to create their windows since they are non-visual controls. Borland created equivalent AllocateHWnd and DeallocateHWnd functions for Kylix in its WinUtils.pas unit so it should be possible to do the same for Lazarus. Without these functions (and related MakeObjectInstance and FreeObjectInstance functions), it might be impossible to port Orpheus to Lazarus.

Thanks.

-Phil

[skywriter]

I think you should not escape from "non-crossplatform" functions because it may limit Lazarus's usability significanly. Even in those approaches where cross-platform-ness could be achieved by combination of several platform-depended ways.
See "Synaser" for example: they use platform-depenent implementaion of functions which are available for use on different platforms.

[Curt Carpenter]

This is a very old thread -- but for future reference by anyone who may try to use AllocateHwnd or DeallocateHwnd in the future:

In Lazarus 0.9.30, the source for these two procedures is in the fpc  subdirectory at  ..\source\rtl\win32\classes.pp then
classesh.inc.

The procedures are there in the code -- but they are only stubs that do nothing except generate a Runerror(217) message.
Hence code that uses these procedures will compile alright -- but will fail at runtime with that error message.