Question about ToolbarWindowProc

[Guy L. Albertelli]

----- Original Message -----
From: "Jeremy Shaw" <jeremy at lindows.com>
To: <wine-devel at winehq.com>
Sent: Thursday, February 21, 2002 4:07 PM
Subject: Question about ToolbarWindowProc


> Greetings:
>
> I am attempting to implement toolbar window message 0x463 -- which, as
> far as I can tell, is undocumented. If anyone has any information
> about it, I would love to hear it.
>
> I currently have a question about a difference in the implementation
> of comctl32.dll under Wine vs Windows. In both Wine and Windows, the
> function ToolbarWindowProc starts by calling GetWindowLongA (hwnd,
> 0) and treats the returned value as a pointer to a structure.

> Under wine the structure is the TOOLBAR_INFO structure defined in
> dlls/comctl32/toolbar.c. Under Windows, I have no idea what the
> structure looks like. Using the debugger, I can see that the first two
> elements of the structure are the hwnd numbers of the window and its
> parent -- but after that it is not very obvious. The structure is over
> 150 bytes in size.
>
> Does anyone know what the structure under Windows looks like?

1. Most (if not all) the extended common controls (those in comctl32) seem
to store their main implementation data via GetWindowLong(hwnd, 0). However
we really don't care about the format of the MS version since our code
*should* never interface with it. I have not personally seen any access to
that in Rebar, Toolbar, or ComboEx. To avoid *trouble* I would suggest
staying away from MS's version of the implementation data.

2. From looking at relay traces, Toolbar messages 0x045d and 0x0463 seem to
be a
pair. They also seem to invoke comctl32.413 which is also undocumented. The
relay traces seem to suggest that .413 somehow redirects the message to
another Winproc. All windows that process through .413 seem to have the atom
for "CC32SubClassInfo" added as a property (GetProp/SetProp). I suspect that
this whole thing may be related to the "nativefont" control. There seems to
be no ill-effect to the messages not being implemented (except for the
annoying fixme).  Note that comctl32.413 may also be related to comctl32.410
and .412.

If you can somehow get the "nativefont" control to make a visual difference,
then maybe we can implement some of this.

Good Luck,

Guy