This fixes the wine_dbgstr_variant() compatibility with non __STDC__
compilers and source code that defines _FORCENAMELESSUNION.
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The code had been checking the kDisplayModeDefaultFlag in the mode's IOFlags,
but that doesn't do what I thought. That indicates which mode the driver
considers to be the default for the hardware. It turns out there's no way to
query the user's default mode.
So, at the first opportunity during a given Wine session, the Mac driver
queries the current display mode and assumes that's the user's default mode.
It records that in a volatile registry key for use by subsequent processes
during that same session.
This doesn't use the existing registry key under
HKEY_CURRENT_CONFIG\System\CurrentControlSet\Control\Video that records the
mode when CDS_UPDATEREGISTRY is used with ChangeDisplaySettingsEx() -- which
explorer.exe does during start-up -- because a) that doesn't support the
distinction between pixel size and point size for Retina modes, and b) in
theory, apps could overwrite that.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This helps to avoid side effects of the not yet finished window creation
process.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Bruno Jesus <00cpxxx@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The various xapofx versions all use the same CLSID to identify the
same effect types. In order to differentiate the versions in Wine
without duplicating a ton of code into each xapofx DLL, I made new
internal CLSIDs for each version of xapofx, which xaudio2_7 registers
and uses to tell them apart.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Bruno Jesus <00cpxxx@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some apps create a zero-sized window as their "main" window and then create
all of the other top-level windows as owned windows with that main window as
the owner. The user interacts with these owned windows. When the user
attempts to minimize one of these owned windows, the app instead minimizes the
zero-sized owner window. When an owner window is minimized, all of its owned
windows are hidden.
The Mac driver faithfully carries out these window operations. The only
visible windows are hidden and the zero-sized window is minimized. This
results in an invisible animation of the window down to a slot in the Dock -
a slot which appears mostly empty. The invisible window thumbnail is badged
with the app icon, but it still looks strange.
On Windows, the Alt-Tab switcher uses the image of the owned window to
represent the zero-sized owner.
This commit attempts to do something similar. It takes over drawing of the
Dock icon for minimized, zero-sized window. It grabs a snapshot of one of the
owned windows and draws the app badge onto it. Since the owned windows are
hidden before the zero-sized owner is minimized and we can't take snapshots of
hidden windows, we use heuristics to guess when it may be useful to grab the
snapshot. If the user minimizes an owned window from the Cocoa side, we grab
that window's snapshot. If an owned window is being hidden and no snapshot has
been taken recently, we grab its snapshot on the theory that this may be the
beginning of hiding all of the owned windows before minimizing the owner.
Unfortunately, this doesn't address the invisible animations when minimizing
and unminimizing the zero-sized owner window.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Francois Gouget