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

Nikolay Sivov bunglehead at gmail.com
Wed Aug 30 01:36:21 CDT 2017


On 30.08.2017 2:06, Fabian Maurer wrote:
> Hi,
> 
> Sorry, but there's a bunch of issues I need to point out. Of course we could 
> address them later, but it'll mean rewriting a bunch of code, and I'd like to 
> have it correct from the beginning. In general, I think this implementation 
> limits us too much.

No, you're right, if it means large changes later it should be done
differently.

> 
> For example, I don't think it's a good idea to have the TASKDIALOGCONFIG 
> structure being filled in run_test_, we need to be able to control it easily.

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

> 
> Second, we also need to be able to return different values in the callback, 
> the current approach doesn't account for that.

Ok, this is easy to add.

> 
> And the most important part, the separation from messages to send and received 
> messages to test against. It's better to send the next message only when the 
> last message arrived, to make sure we process them in the correct order.
> I attached a patch to show the problem (apply on top of my in-review patch). 
> When sending all messages together, the first message is skipped, and we don't 
> want that to happen.

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?

I'll look into that.

> 
> Please reconsider my approach, I can try to simplify it if you want, but I 
> think the complexity is justified to solve a complicated problem.

Yes, I will, thanks for your comments.

> 
> Regards,
> Fabian Maurer
> 
> 
> 
> 




More information about the wine-devel mailing list