[PATCH v2 1/2] winex11.drv: Activate window when restoring from iconic state.

[Dmitry Timoshkov]

Zhiyi Zhang <zzhang at codeweavers.com> wrote:

> >> #2 The reason why Mirror's Edge doesn't handle WM_SYSCOMMAND SC_RESTORE
> >>
> >> Disassembly of the game win proc shows that the win proc return 0 directly
> >> when handling WM_SYSCOMMAND SC_RESTORE in fullscreen mode, instead of
> >> handing it to DefWindowProc or do any sort of processing. So this means
> >> it rely on the WM_ACTIVATE message before WM_SYSCOMMAND.
> > It should be possible to add a message test that replicates this behaviour.
> I couldn't find a way to do it automatically. It seem an interactive test is required if we really need a test.

In Windows UI practically everything could be reproduced with a set of
API calls, I don't see a need for an interactive test either since you
can't then reliably record and test a message sequence.

> >> @@ -1266,6 +1266,8 @@ static void handle_wm_state_notify( HWND hwnd, XPropertyEvent *event, BOOL updat
> >>              {
> >>                  TRACE( "restoring win %p/%lx\n", data->hwnd, data->whole_window );
> >>                  release_win_data( data );
> >> +                if ((style & (WS_MINIMIZE | WS_VISIBLE)) == (WS_MINIMIZE | WS_VISIBLE))
> >> +                    SetActiveWindow( hwnd );
> >>                  SendMessageW( hwnd, WM_SYSCOMMAND, SC_RESTORE, 0 );
> >>                  return;
> > According to your spy++ logs activating a minimized window before sending
> > WM_SYSCOMMAND/SC_RESTORE is the result of a SetWindowPos call. A message
> > test should help to figure it out its exact flags, in any case it's wrong
> > to call SetActiveWindow directly.
> >
> I don't think that specific WM_ACTIVATE message is the result of SetWindowPos because
> WM_ACTIVATE message is sent after WM_WINDOWPOSCHANGED.

That could be a defect in your testing, a message case would show that
for sure.

-- 
Dmitry.