FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier
Alexandre, Is these changes looks good? Do I have to submit this patch to 'wine-patches(a)winehq.org' ? Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes:
No, it is required. The DEFDLG_SetDefButton() is also called from message DM_SETDEFID. In this case idResult should set to the default button ID passed. And the current logic of DEFDLG_SetDefButton() does what is required for DM_SETDEFID.
Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org
Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes:
Alexandre, Is these changes looks good? Do I have to submit this patch to 'wine-patches(a)winehq.org' ?
Well, I'm not really happy with it, that whole bSetDefID thing is fairly ugly IMO. I'd really appreciate if you could write a regression test that illustrates the behavior of both DM_SETDEFID and WM_NEXTDLGCTL so that the code can be restructured in a more readable way. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Krishna Murthy