combo - implement GetComboBoxInfo

[Thomas Weidenmueller]

Dmitry Timoshkov wrote:

> Since you didn't provide your test app I wrote my own (attached).
> My comments are based on its results.
>  
>
Well, since I was lazy I wrote it in Delphi and you'd have to enter 
window handles yourself, I didn't attach it but since I keep being 
accused of tainted sources I tried to clarify this.

>> 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.
>  
>
That's right, the reason I mentioned is that Christoph's implementation 
won't work because of different address spaces. Even if it points to the 
desktop heap (which ReactOS doesn't have yet) it's not guaranteed to 
work because it might have gotten mapped to another base address. So the 
implementation basically can't work this way.

>> 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.
>  
>
I of course only checked if a message would get dispatched to the window 
procedure of the owning thread. I don't know how windows handles it 
internally but I assume it reads the information from the desktop heap 
without reading the ptr using GetWindowLongPtr. If of course might send 
an internal message that only gets dispatched internally, but that'd be 
much overhead that could easily be a avoided. I forgot to mention that 
the function even works if the thread that owns the combo box hangs, it 
immediately returns the requested information. So sending a (internal) 
special message is not likely in my opinion.

>> 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.
>  
>
That however only works for controls owned by a thread of the same process.

>> 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.
>  
>
That actually is common in the native api. Unless the buffer needed may 
vary depending on the content it returns, in most cases the size fields 
have to match. There are however a few exceptions I found by tests. One 
reason however might be to support different structure versions (.e.g. 
GetVersionEx()). So I don't think it's a "bad thing(tm)". Plus you might 
find bugs caused by using incorrect structure layouts.

> In Wine we can always send our custom WINE_GETCOMBOBOXINFO message if 
> a window
> belongs to other process.
>  
>
Unless the window owner thread hangs, that then causes the caller to 
hang as well, which is not the case in windows. Sending a message with a 
timout would not work correctly if the system is too busy to process the 
request in time, even if the target thread doesn't hang.

> My test app shows that Windows correctly handles a superclassed 
> window, so
> the thesis that it checks the class name is wrong.
>  
>
As I haven't tested that case, I guess you're right.

Best Regards,
Thomas