combo - implement GetComboBoxInfo
dmitry at baikal.ru
Tue Mar 15 19:21:39 CST 2005
"Thomas Weidenmueller" <wine-patches at reactsoft.com> wrote:
Since you didn't provide your test app I wrote my own (attached).
My comments are based on its results.
> The results of the research I just did:
> 1. GetComboBoxInfo works with all handles, even with handles not
> belonging to the calling process
Most likely it's true.
> 2. It does NOT send a message, not even in the case it doesn't belong to
> the calling process
True, but that might be an internal message catched by the message handling
> 3. It sets the last error code to ERROR_WINDOW_NOT_COMBOBOX and returns
> FALSE if the window handle isn't a combo box
True. That might be accomplished by retrieving a window data pointer with
GetWindowLongPtrW and testing some internal fields.
> 4. It sets the last error code to ERROR_INVALID_MENU_HANDLE and returns
> FALSE if the window handle is invalid
ERROR_INVALID_WINDOW_HANDLE as corrected.
> 5. If the cbSize field of the COMBOBOXINFO structure doesn't match, it
> sets the last error code to ERROR_INVALID_PARAMETER and returns FALSE
Poor Microsoft programmers even decided to fail if cbi.cbSize = sizeof(cbi) + 1,
i.e. if it's enough space to store the result.
> Because of 1. and 2. it's only possible to implement it in win32k unless
> one wants to determine the window owner,
> open a process handle and read the memory, a win32k implementation would
> be cleaner.
In Wine we can always send our custom WINE_GETCOMBOBOXINFO message if a window
belongs to other process.
My test app shows that Windows correctly handles a superclassed window, so
the thesis that it checks the class name is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2266 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050316/bc4d6c00/combo.obj
More information about the wine-devel