We only care if we have changed the mode and we're changing it back to its
original. Even if the current mode matches the target mode, we may still
need to release the displays and clear the entry from originalDisplayModes.
originalDisplayModes should be used when active, empty when inactive.
latentDisplayModes is used when inactive, empty when active.
The count of entries in originalDisplayModes is used to test whether the
process has the displays captured so adding entries when inactive would give
incorrect results. This could have led us to mistakenly change the display
mode when we don't have the displays captured.
Among other things, this fixes Syberia 2. That game shows, hides, and then
shows its window. Hiding it caused a WINDOW_LOST_FOCUS event to be queued.
By the time it was processed, the window was the foreground window again.
In response to being told it had lost focus, the game minimized its window.
Hiding the window should have prevented or discarded the WINDOW_LOST_FOCUS
event since the change was driven from Wine and the Win32 foreground/active
window state would already be correct. In addition, when the program
re-showed its window and made it foreground, that should have discarded the
event as being out of date. Now they do.
The Win32 window state might have changed while the event was in the queue,
making it obsolete. Sending WM_SYSCOMMAND/SC_RESTORE might re-show a hidden
window, for example.
Cocoa would implictly unhide it when we order a window, anyway. Doing it
early avoids problems from querying -[NSWindow isVisible] while the app is
hidden. That method returns FALSE even for windows which would be visible
if the app weren't hidden.
The -[NSWindow isVisible] method returns FALSE when the process is hidden,
but that's not what we need to know in some cases.
This fixes full-screen games which minimize their window when they lose
focus. Command-Tabbing away hides the process. Because the window was not
visible, the code didn't actually minimize it. When switching back to the
process, no event was sent to the Wine back-end telling it the window had
been restored, so it never resumed drawing to it.
The user is prevented from moving or resizing a maximized window. The zoom
button is still present and enabled for a maximized window but requests that
it be restored rather than simply resizing it, which is what it does for
normal windows.
If a window is not resizable (lacks WS_THICKFRAME) but has a maximize box
(WS_MAXIMIZEBOX), then the zoom button requests that it be maximized rather
than resizing it.
The window menu items are not updated as the window state changes; they only
update when the menu is shown. So the item state is not a reliable indicator
of whether minimization is allowed.
Fixes a problem in some games which repeatedly (re)establish the same cursor
clipping rect, making it exceedingly difficult to move the camera with the
mouse.
This simulates some of what would happen if user32 were managing the drag. The
click in the caption would cause WM_SYSCOMMAND/SC_MOVE. The processing of that
message is synchronous and doesn't return until the move is complete.
Some games require that "blocking" in the internal event loop to prevent them
from misbehaving during the drag.
This fixes a problem where some apps move their window to the front after
the user switches away to another app. OS X prevents the background app
from actually coming in front of the active app's front window, but the
window gets ordered in second place, possibly obscuring other windows of the
active app.
New clipboard formats had been registered for them, but that was pointless.
No Windows app would ever expect or make use of such clipboard formats or the
associated pasteboard data.
It has a non-object pointer from the caller, so it can't allow the caller
to continue until it's finished with it. Also, it discards events from the
event queue and we don't want the caller to process them first.
Fixes brokenness introduced by 784a9139.
Ken Thomases