[Bug 19052] Animation Shop: crash at startup

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=19052


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|DUPLICATE                   |




--- Comment #8 from Anastasius Focht <focht at gmx.net>  2010-07-08 17:14:06 ---
Hello,

--- quote ---
What's the simplest way to create a test case for this behaviour? Creating a
not visible overlapped, and then a visible popup windows work same way under
Wine as they do under Windows (i.e. GetFocus() and GetActiveWindow() return
same active and focus windows). Are there any SetWindowPos, SetParent,
ShowWindow that required to replicate the bug?
--- quote ---

Well, after endless hours of looking at win/msg (spy) trace logs and debugging
I came to conclusion this might not be an exact dupe of bug 5402 - even if the
hack from there seems to fix the problem.
That hack will "fix" all kinds of active/foreground window/control/focus bugs
hence it's very difficult to work out the exact cause for each of the
applications listed.

As I already mentioned in previous comment, the active window state/focus is
not given to right window/control.
The problem seems to be caused by a dialog bar control, created from template
(along with several child controls), which is a child of the top level main app
window.

---

(1) top level (main app window): 

Title="Jasc Animation Shop"
 Parent=topmost
 Style=0x4CD8000
(WS_OVERLAPPED|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION|8000)
 ExtStyle=0x100 (WS_EX_WINDOWEDGE)
 Class=Afx:400000:8:10011:0:120487

(2) splash window

 Parent=(1)
 Style=0x94000000 (WS_POPUP|WS_CLIPSIBLINGS|WS_VISIBLE)
 Class=Afx:400000:0

(3) dialog bar control

 Parent=(1)
 Style=0x40000044 (DS_3DLOOK|DS_SETFONT|WS_CHILD)
 ExtStyle=0x80 (WS_EX_TOOLWINDOW)
 Class=#32770

(4) first child control of dialog bar

 Title=O
 Parent=(3)
 Style=0x50020001 (SS_CENTER|WS_CHILD|WS_GROUP|WS_VISIBLE)
 ExtStyle=0x4 (WS_EX_NOPARENTNOTIFY)
 Class=Static

...
(other childs, same level, similar styles)
---

Before the creation of the dialog bar using CreateDialogIndirectParamA(), the
splash window has the input focus/active window state.
After the creation of the dialog bar
(dlls/user32/dialog.c:DIALOG_CreateIndirect()), the splash still has input
focus which seems wrong, leading to crash.

Relevant code that deals with focus/input state change after WM_INITDIALOG is
processed:

--- snip dlls/user32/dialog.c ---
static HWND DIALOG_CreateIndirect( HINSTANCE hInst, LPCVOID dlgTemplate,
                                   HWND owner, DLGPROC dlgProc, LPARAM param,
                                   BOOL unicode, BOOL modal )
{
....

    /* Create controls */

    if (DIALOG_CreateControls32( hwnd, dlgTemplate, &template, hInst, unicode
))
    {
        /* Send initialisation messages and set focus */

        if (dlgProc)
        {
            HWND focus = GetNextDlgTabItem( hwnd, 0, FALSE );
            if (SendMessageW( hwnd, WM_INITDIALOG, (WPARAM)focus, param ) &&
                ((~template.style & DS_CONTROL) || (template.style &
WS_VISIBLE)))
            {
                /* By returning TRUE, app has requested a default focus
assignment.
                 * WM_INITDIALOG may have changed the tab order, so find the
first
                 * tabstop control again. */
                dlgInfo->hwndFocus = GetNextDlgTabItem( hwnd, 0, FALSE );
                if( dlgInfo->hwndFocus )
                    SetFocus( dlgInfo->hwndFocus );
            }
        }
...
--- snip dlls/user32/dialog.c ---

There is no other code involved that can force focus/activation change before
the crash hence I suspect GetNextDlgTabItem() might not be working correctly.

None of the child controls have WS_TABSTOP style bit set hence
GetNextDlgTabItem() (with input hwndCtrl NULL) returns NULL for both: before
WM_INITDIALOG is sent (hFocus param) and after WM_INITDIALOG.

Although MSDN states different, I modified Wine's DIALOG_GetNextTabItem()
helper to return the first child when no control with tabstop property was
found.
With that change - focus set to first child (with hwndCtrl = NULL, fPrevious =
FALSE) - the top level app window got active state again and the application
"JASC Animation Shop 3" successfully started.

It might not be correct but it's the best I came up with.
A testcase will be needed to prove or disprove this strange tabstop+focus
assignment behaviour.

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.