[Bug 38829] Jammer Pro 6 crashes on file open

https://bugs.winehq.org/show_bug.cgi?id=38829

Michael Müller  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #3 from Michael Müller  ---
Created attachment 51775
  --> https://bugs.winehq.org/attachment.cgi?id=51775
Patch to add a check if fodInfos is NULL

I attached a patch which fixes the issue. I am not sure though if there is a
better way to handle this problem.

I will explain what causes the issue, maybe someone comes up with a better
approach. So here is what happens:

1. The applications calls GetOpenFileNameA and defines a custom template with
custom controls (!).
2. The dialog is created and FileOpenDlgProc95 is called with WM_INITDIALOG.
The function saves the custom dialog information:
   SetPropA(hwnd, FileOpenDlgInfosStr, fodInfos);
3. The users closes the dialog (for example by clicking Cancel).
DIALOG_DoDialogBox leaves the message loop and calls FileOpenDlgProc95 with
WM_DESTROY which removes the custom dialog information again:
   RemovePropA(hwnd, FileOpenDlgInfosStr);
4. DIALOG_DoDialogBox destroys the dialog window using DestroyWindow.
DestroyWindow first destroys the child windows and sends WM_DESTROY to one of
the custom controls.
5. The custom control receives the message and calls SetWindowText on an edit
control:
6. The edit control changes the text and informs the parent window using
SendMessage (in EDIT_WM_SetText). The parent window in this case is the dialog
window.
7. The dialog proc is called (although we already left the message loop) and
FILEDLG95_OnWMCommand tries to process the message.
8. FILEDLG95_OnWMCommand tries to get the custom dialog information and
deferences them:
  FileOpenDlgInfos *fodInfos = GetPropA(hwnd,FileOpenDlgInfosStr);
  [...]
  fodInfos->DlgInfos.dwDlgProp &= ~FODPROP_USEVIEW;
9. CRASH ;-)

Obviously the dialog proc function was not supposed to be called any more. I am
not sure if one of those window functions is supposed to fail since we are
already destroying the window or if the application is really doing something
dangerous here. We can workaround the problem by checking if fodInfos is NULL
in FILEDLG95_OnWMCommand (as I did in the patch). However, this wouldn't fix
the issue for other window messages like WM_SIZE. Maybe we should add such
checks everywhere in FileOpenDlgProc95?