FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

[Krishna Murthy]

Alexandre,
Is these changes looks good? Do I have to submit this patch to
'[e-mail]' ?
Thanks,
Krishna

-----Original Message-----
From: Krishna Murthy 
Sent: Tuesday, June 22, 2004 2:56 PM
To: 'Alexandre Julliard'; Krishna Murthy
Cc: [e-mail]
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:[e-mail]]
Sent: Friday, June 18, 2004 10:30 AM
To: Krishna Murthy
Cc: [e-mail]
Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not
rest ore default control identifier

Krishna Murthy  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
[e-mail]

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

[Alexandre Julliard]

Krishna Murthy  writes:
> Alexandre,
> Is these changes looks good? Do I have to submit this patch to
> '[e-mail]' ?

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.