Created attachment 21977 [details]
The wine dialog is warning me that something bad happened.

Does the demo have the same problem? http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Editors/Animation-Shop.shtml

is this still an issue in current (1.2-rc2 or newer) wine?

Created attachment 28573 [details]
bzipped +relay,+seh,+tid log (uncompressed size 7.2 MB)

The demo crashes in the same way, using wine-1.2-rc2-111-g9aa9a12.

Hello,

dupe of bug 5402
Application is MFC based which seems to be the common denominator, exhibiting the behaviour.

There are two top level windows and at the time of the crash, the splash window is treated as active window which is wrong (although foreground+active -> being shown).
The main app window -> not being shown <- should be the active one.
When the window handle from GetActiveWindow() is mapped to C++ instance data, member data is accessed at wrong offsets (due to different class layout), hence the crash.

Regards

Dup.

*** This bug has been marked as a duplicate of bug 5402 ***

Closing dup.

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?

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

Thanks for the analysis Anastasius. I've asked same question in the bug 5402
what's the simplest way to create a test case for the bug.

Hello,

--- quote ---
Thanks for the analysis Anastasius. I've asked same question in the bug 5402
what's the simplest way to create a test case for the bug.
--- quote ---

Well it became some kind of metabug due to wide range of the hack.
I have to dissect each of the apps listed in bug 5402 - that takes some time.
It might even require splitting into more bugs to target each of these apps.

Fortunately, a quick check showed that one of the apps mentioned in bug 5402 - "Samsung PC Studio PIMS II II 1.0" - suffers from same dialog bar control tabstop/focus assignment issue analysed here.

--- quote ---
-------  Comment #20 From  Louis Lenders   2008-06-10 15:33:33  -------

here's yet another one crashing because if this bug:

Samsung PC Studio PIMS II II 1.0 (Win 98/ME/2K/XP) for free at:
http://nl.samsungmobile.com/supports/softwaremanuals/software.do?phone_model=SGH-X510&sw_type=SW
--- quote ---

Download URL: http://downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?VPath=SW/200610/20061016131758640_Pims_File_Manager.exe

My modification to DIALOG_GetNextTabItem() also lets this app successfully start (needs winetricks jet40 though).

Regards

Does
http://source.winehq.org/git/wine.git/?a=commitdiff;h=1bf5e12e9593b7c8cfd14a2c114c17371737f2c3
make any difference?

Hello,

--- quote ---
Does http://source.winehq.org/git/wine.git/?a=commitdiff;h=1bf5e12e9593b7c8cfd14a2c114c17371737f2c3
make any difference?
--- quote ---

nope, the change is unrelated.

Regards

After winetricks jet40 I can run the application PIMS & File Manger from comment 10 in wine-1.6-rc2-32-g407584f.

a80bad8941338c490b7f2be961c0b2c2c6846e74 20061016131758640_Pims_File_Manager.exe

Maybe fixed?

Hello folks,

this was fixed some years ago by commit http://source.winehq.org/git/wine.git/commitdiff/59c398b8ed46e0852386ad913c0f0a658a196523 

Thanks Alex

Both, 'Jasc Animation Shop' and 'Samsung PC Studio PIMS II 1.0' start fine without crashing.

Regards

Closing bugs fixed in 1.7.10.