----- Original Message ----- From: "Jeremy Shaw" jeremy@lindows.com To: wine-devel@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