combo - implement GetComboBoxInfo

[Dmitry Timoshkov]

"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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: combo.c
Type: application/octet-stream
Size: 2266 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050316/bc4d6c00/combo.obj