Apparently changing the window scrollbars in the middle of a window
deferred repositioning operation is not allowed and confuses
EndDeferWindowPos() which doesn't update the position of _grand_
children correctly in this case.
This bug notably manifested itself when loading a wxScrolledWindow
containing wxStaticBox from XRC, as the parent window was initially
created with the default small size and then relaid out when it was
resized to its real size on first wxEVT_SIZE event which also updated
the scrollbars. As a result, the children of the wxStaticBox were
shifted downwards.
The fix simply flushes the current repositioning operation and starts
one anew in wxWindow::SetScrollbar().
This doesn't really change anything, but just skips executing some code
uselessly if we know in advance we are not going to do anything, which
is nice as ScrollWindow() actually ends up being called with 0 arguments
surprisingly often from wxScrollHelperBase::SetScrollRate().
This is also consistent with what wxGTK does.
This reverts commit e771b7e4ac.
Don't always pass WM_SYSKEYDOWN to the system for processing as this can
be undesirable: e.g. inside a dialog, any Alt-X key presses with X not
being a mnemonic character result in a beep from IsDialogMessage().
Handle events for the system keys in the same way as for the normal
ones, i.e. let the system process them only if they're not handled by
the application.
This is incompatible with the previous wxMSW behaviour, but compatible
with the other ports and makes more sense, so it seems to be worth it,
on balance.
The callback must return LRESULT, which is 64 bits under Win64, not
int, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
This parameter wasn't used anyhow and casting wxWndProc or m_oldWndProc
to WXFARPROC just resulted in gcc8 -Wcast-function-type warnings.
Get rid of them by not passing the window proc to this function at all.
The test for AUX2 mouse button was wrong and checked whether the button
was pressed, instead of checking whether the event was generated by it.
Check the event source correctly by comparing wParam with XBUTTON2 and
not MK_XBUTTON2.
Closes https://github.com/wxWidgets/wxWidgets/pull/753
Clearing this style by calling SetWindowStyleFlag() could reset
WS_EX_CONTROLPARENT extended flags bit, breaking the invariant that the
parent of any window with this bit set has it as well and resulting in
hangs due to infinite loops inside Windows own code iterating over the
controls.
Prevent this from happening by always preserving this style bit if it
was previously set in MSWUpdateStyle(). This is a bit ugly, but there
doesn't seem to be any obviously better way to do it.
Closes#18091.
Composite windows, i.e. wxWindows composed of several HWNDs at MSW
level, didn't handle focus events correctly and, for example, generated
wxEVT_KILL_FOCUS event when the focus simply switched from wxComboBox
itself to the EDIT control inside it, which broke using non-readonly
wxComboBox as in-place editor inside wxDataViewCtrl.
Check if the focus event notifies about the focus switching to, or from,
another HWND belonging to the same window, and suppress wx event
generation in this case as they don't make sense because the focus
doesn't change at wx level.
See #17034.
Remove various definitions and symbol declarations from
numerous files using msw/uxtheme.h to a single file.
When possible vssym32.h is included from the Windows SDK.
For older SDKs tmschema.h is included and missing symbols
are defined in msw/uxtheme.h.
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
Since the switch to using an event object for idle handling wakeup,
WM_NULLs are not being sent any longer, so wxIdleWakeUpModule didn't do
anything, resulting in pending event dispatching being paused while our
event loop was not running, as it happened, for example, while the
window was resized.
See #17579.
Add wxMSWWinStyleUpdater and wxMSWWinExStyleUpdater helper classes which
allow writing code changing GWL_STYLE and GWL_EXSTYLE bits,
respectively, in a shorter and more clear way.
There should be no real changes in behaviour.
Implement support for enabling just some gesture events instead of
having to choose between getting none or all of them.
Also make wxTOUCH_NONE really disable the gestures events generation
instead of just doing nothing as before.
Don't request touch event generation for all windows by default, this
has an inherent overhead and is not needed for 99% of the application
windows, so require calling EnableTouchEvents() explicitly to do it
instead.
Note that this requires properly initializing gesture recognizers in
wxOSX now that they're not always allocated, otherwise releasing them
when destroying the window would crash.
Don't repeat the same code for initializing events in several different
functions but put it in a helper InitGestureEvent() function and just
call it from the event-specific handlers.
Document that the users of this class always must call IsOk() first, as
they already do, and remove the checks for ms_gestureSymbolsLoaded and
calls to LoadGestureSymbols() from all the other methods, which are
unnecessary in this case.
This shouldn't be needed any more, after the previous commit which
replaces the raw pointer to the focused child in wxTopLevelWindowMSW
with a safe weak reference.
WM_CONTEXTMENU message is generated directly by the system when the user presses and releases the VK_APPS key so there is no need to do this by emulating right mouse button click.
Closes#17969.
Some current input processing flags, like DLGC_HASSETSEL, should be retained because they are in use (in wxWindowMSW::SetFocusFromKbd() for instance).
Closes#17945.
Adjust the size and position we're about to set before comparing them
with the current ones, otherwise the result of the comparison could be
wrong when width and/or height are -1.
See #17075.
The symbols in question are present at least since XP, and most of them since
Windows 2000, so remove preprocessor checks for them, they shouldn't be needed
when any remotely current compiler/SDK.
This is not necessary any longer, we don't support Windows CE any more and
these constants are available since Windows 2000 in the desktop Windows SDKs.
This method allows to use the Windows class to use for the window being
created instead of always using "wxWindow" or "wxWindowNR".
This can be useful to make it possible to handle some windows specially from
outside the application, e.g. use specific class names for accessibility
purposes as will be done by the next commit.
Determine which class name to use in MSWCreate() caller instead of doing it
partly there and partly in MSWCreate() itself, which used to add the "NR"
suffix if necessary -- now it doesn't do this any more and just really created
the window using the given class.
No real changes, just prepare for future enhancements.
If the position changed but the size didn't, we just call Win32 API for
updating the window geometry but it didn't generate WM_SIZE in this case, so
even when wxSIZE_FORCE_EVENT was used, no wxSizeEvent was sent.
Toplevel windows use their parent's coordinate system as the reference
frame, not desktop's, so need to be adjusted accordingly if its
mirrored. Without these changes, default-positioned wxDialogs would end
to the right side of the parent window's right border (instead of being
slightly inside the window) and changing their size would move them as
well.
To correctly compute the brush origin offset for painting background of a
child in a window using RTL layout, we need to offset it by the child origin
i.e. its _right_ top corner in this case and not the left top corner as we did
before.
Conveniently, although not very explicitly, MapWindowPoints() already takes
care of this for us if we just pass it both the left and right points, but we
wrongly passed it only a single one, so it couldn't work its magic in this
case.
Change this to fix the drawing artefacts which appeared over wxNotebook
children with transparent background (e.g. wxStaticText) due to the use of
wrong origin before.
Don't define BeginRepositioningChildren() and EndRepositioningChildren() at
all in this case instead of defining them as "do nothing" functions because
BeginRepositioningChildren() still needs to return a bool, so the old code
didn't compile and we would need to add another "#else" to fix this -- instead
make it simpler by just not compiling at all in this case.
