Alexandre Julliard wrote:
Much worse, the class name is not a valid way of checking the Windows type. You really need to send a message.
The results of the research I just did:
1. GetComboBoxInfo works with all handles, even with handles not belonging to the calling process 2. It does NOT send a message, not even in the case it doesn't belong to the calling process 3. It sets the last error code to ERROR_WINDOW_NOT_COMBOBOX and returns FALSE if the window handle isn't a combo box 4. It sets the last error code to ERROR_INVALID_MENU_HANDLE and returns FALSE if the window handle is invalid 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
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.
Sure, win32k doesn't exist in wine so it's a task for wineserver.
Just for the record: I wrote a very basic test application where I can enter a window handle, in combination with MS Spy++ it just takes < 5 minutes to find out. A simple SetLastError(0) before the function call and a GetLastError() after it revealed the error codes. print everything to the screen and modify the cbSize parameter and you got all the information. If you insist I can attach the test application as a proof, but you have to enter window handles yourself and run MS Spy++.
This information was gathered in less than 5 minutes by just testing, no reverse engineering or whatsoever was involved. However, since it might set the last error code to ERROR_WINDOW_NOT_COMBOBOX I expect it to check the window class name.
Best Regards, Thomas