[PATCH 1/2] comctl32/taskdialog: Initial support for callback procedure

[Fabian Maurer]

Hello,

thanks for the quick response.

> I have no problem with that, except for maybe initializing
> size/callback/user data in run_test still.

Yes, since that's always the same that makes sense. It's a minor issue really, 
we could pull it out later, too, but we too could just define it outside from 
the beginning.

> Ok, this is easy to add.

If this is so, don't mind this. I just didn't know whether we could fit that 
into the message structure, too.

> What do you mean by last message arrival? Currently all messages to
> control are posted, so we don't wait for anything but rely on callback
> to be called eventually. Do you mean that you want to specify message to
> be sent to control for every callback individually, like for example in
> mes_cancel_esc_callback1 - WM_KEYDOWN is sent in response to TDN_CREATED
> and TDM_CLICK_BUTTON in response to TDN_BUTTON_CLICKED?

Basically yes. Right now all messages are posted at once, and that's where we 
run into problems. When running my patch on a win7 machine, 
mes_cancel_esc_callback1 succeeds while mes_cancel_esc_callback2 fails. For 
some reason the "M_KEYDOWN, VK_ESCAPE" message is completely ignored, and we 
get IDOK.
E.g., modify it like
------
static const struct message_info mes_cancel_esc_callback2[] = {
    { TDN_CREATED, 0, 0, S_OK, {
        { WM_KEYDOWN, VK_ESCAPE, 0 },
        { TDM_CLICK_BUTTON, IDOK, 0 },
        { 0 }}},
    { TDN_BUTTON_CLICKED, IDOK, 0, S_OK },
    { 0 }
};
------
and it works fine again. As you see, this is something that shouldn't happen. 
Honestly, I have no idea why that happens, maybe you know more. Could be that 
I'm just doing something really wrong, but this is the reason I switched to 
the new strategy - sending the new messages after the old were processed. I 
just found it to be way more reliable.
I'm fine with a different strategy of course, it's just that this was the only 
way I managed to solve this particular issue.


On a site note, the second test fail with
------
taskdialog.c:213: Failed sequence Cancellation: stopped by callback 2:
taskdialog.c:213:   0: expected: nothing - actual: 8000 wp 00000000 lp 
00000000
taskdialog.c:213:   1: expected: nothing - actual: 8000 wp 00000000 lp 
00000000
taskdialog.c:213:   2: expected: nothing - actual: 8000 wp 00000001 lp 
00000000
taskdialog.c:213:   3: expected: nothing - actual: 8000 wp 00000000 lp 
00000000
------
and that's obviously wrong. Attached a quick hack, I assume this is a bug in 
the msg.h implementation.


Regards,
Fabian Maurer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dunp-sequence-correctly.patch
Type: text/x-patch
Size: 1142 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170830/b0b88937/attachment.bin>