"Thomas Weidenmueller" <wine-patches(a)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 code.
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. -- Dmitry.