[PATCH v5] comctl32: Implement handling of EM_SETCUEBANNER/EM_GETCUEBANNER messages.

[Sergio Gómez Del Real]

On 28/10/18 6:47 a. m., Nikolay Sivov wrote:
> On 10/27/2018 11:10 PM, Sergio Gómez Del Real wrote:
>
>>
>>
>>>> +    case EM_SETCUEBANNER:
>>>> +        result = EDIT_EM_SetCueBanner(es, (const WCHAR *)lParam);
>>>> +        break;
>>> How did you test wParam flag? It seems to work for me as docs describe.
>>>
>> I tested writing a sample program on Windows 7, 32-bits. On that same 
>> OS, I got the same results using ControlSpy (for WPARAM it said it 
>> was unused). Then I googled a bit and read at a couple of places that 
>> indeed 'Windows' ignores that flag; it always behaves as if WPARAM is 
>> 0. That is not enough to conclude that all versions of Windows behave 
>> the same, of course. What version did you try, and what should we do 
>> with this OS dependence?
>>
>>
> I tested on Windows 10. You're right, I don't see it in 2k3 SDK, in 
> SDK 10.x they have new macro for this, everything still guarded with 
> XP version. For our implementation it's enough to have a fixme for 
> now, if it's not working with Win7. If you can't test on Win10 right 
> away, feel free to send me your test program.
>
I've just tested on Windows 10, and re-tested on Windows 7, and it is 
working as you said on both platforms. That is, if wParam is TRUE, the 
text is shown even when the control is focused (but not when you write 
something in it, of course). The macro Edit_SetCueBannerText() doesn't 
include this option, though, but since it is still an option to send the 
message explicitly, instead of using the marco, I think I'll add the 
FIXME and come back to it later (since now it is possible to overwrite 
that behavior, so that must be added to tests, and I'm a little caught 
with other things).