When WM_STATE is being quickly updated, and depending on the WM we might
receive transient focus changes, which will disrupt the Win32 state and
make us randomly lose focus.
Ignore them instead, when a window is being shown, and wait for WM_STATE
to be updated and stable. We will eventually receive a WM_TAKE_FOCUS /
FocusIn event *after* a window has been shown.
When a window is hidden or minimized, we will receive the FocusOut event
during the WM_STATE transition, and can safely handle it in this case,
as we should have done all the Win32 side effects and have changed the
foreground window already.
When there's no window state change pending, the focus change event is
unexpected, coming from the user or WM, and we handle it normally.
It's worth noting that comctl32 v6 have hottracking notifications enabled
by default, there is no need to set any extended styles.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Esp. the failures with ERROR_BAD_EXE_FORMAT still fill all the fields
in the returned structure.
Add more flexibility to .dbg file creation (optional DEBUG_DIRECTORY).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
We won't receive a ConfigureNotify event if the embedded window has been
reparented without moving or resizing it. Top-level windows always
receive synthetic ConfigureNotify from the window manager.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
The X event merging logic removes events from the queue in advance, and
putting a dummy ConfigureNotify back in the queue will override any
previously received event.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
Instead of keeping the same offset as from the previous window parent,
which may cause offsets to stack up with embedded windows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57370
We have to introduce special handling for jscript, as it's probably integrated
on native mshtml.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
When GLOBAL_DISPEXVAR is used, we store the id of the dynamic prop and
invoke it using the same id. But this is not the case if we have a jsdisp,
which is redirected from InvokeEx and results in an invalid id.
The actual way this works on native (in IE9+) is that element/frame props
are special and not part of the window object at all. They're actually
looked up after the prototype is, in a special way, but that requires a
revamp. Storing over it just creates an actual prop on the window (which
is what we are doing here).
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
