"Thomas Weidenmueller" wine-patches@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:
- GetComboBoxInfo works with all handles, even with handles not
belonging to the calling process
Most likely it's true.
- 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 code.
- 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.
- 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.
- 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.