"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> Thanks. Would you be able to share details of the changes you did for
> handling MDI windows?
The patch is here: http://cvs.winehq.com/patch.py?id=10783
I think that (almost) all that needs to be done about the problem is to move
most of the D
CTED]
> Subject: Re: Handling dialogs created without using templates
>
> "Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
>
> > Yes attached is a sample which is pretty similar to what I described
> > below.
>
> Thanks. Now I see where the p
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> Do you have a solution to this issue? If yes, are you planning to
> introduce it soon?
No, I have no a solution yet. Developing such a solution requires
to write a lot of regression/conformance tests. i.e. find out how
Windows hooks dialog crea
heshwar
> Cc: [EMAIL PROTECTED]
> Subject: Re: Handling dialogs created without using templates
>
> "Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
>
> > Yes attached is a sample which is pretty similar to what I described
> > below.
>
> T
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> Yes attached is a sample which is pretty similar to what I described
> below.
Thanks. Now I see where the problem is. We have to hook dialog creation
code into common window creation code, something similar to what I've done
recently for MDI. A
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> I have an application that creates dialogs without using any of the Win32
> Dialog creation APIs. I find that a lot of the
> functionality in DEFDLG_Proc (DM_SETDEFID, DM_GETDEFID & WM_NEXTDLGCTL) is
> unavailable for use with
> dialogs created
Hi,
I have an application that creates dialogs without using any of the Win32
Dialog creation APIs. I find that a lot of the
functionality in DEFDLG_Proc (DM_SETDEFID, DM_GETDEFID & WM_NEXTDLGCTL) is
unavailable for use with
dialogs created this way. This is because we allocate the DIALOGINFO
st
