This doesn't work anyhow, so it's better to prevent the code doing this
from compiling instead of getting run-time asserts or worse.
Also simplify construction of these events inside wxWidgets by passing
the window itself to the ctor instead of passing just its ID and calling
SetEventObject() separately later.
For consistency, do the same thing for wxNcPaintEvent too.
Creating wxPaintDC for a window outside of any wxEVT_PAINT handler
already resulted in assert failures and crash due to using the empty
wxDidCreatePaintDC stack, but the assert message was not really clear,
so improve it by stating explicitly that wxPaintDC can only be created
from wxEVT_PAINT handlers.
Also check that wxPaintDC is being created for the correct window: this
wasn't detected at all before, but could still result in a lot of grief,
so check for this too.
Finally, create a new private header with the paint data stack variable
declaration instead of using "extern" to declare it manually in wxDC
code.
This is unnecessary, we only need to update the pending focus in the
immediate parent window to prevent a wrong radio button from being
focused (and hence selected) when it regains focus, there is no good
reason at all to interfere with the focus in the grandparent (and
higher) windows.
Doing this was not only useless, but actually harmful, as it overrode
explicit calls to SetFocus() in the user code, so just stop doing it.
This also allows to avoid having 2 functions related to this and keep
just a single virtual WXSetPendingFocus() one.
Closes#18653.
Put common code from all the different ports into it.
This is not very useful right now, but it will allow to change this
function once, instead of applying the same change to all ports, in the
upcoming commit.
If wxEVT_PAINT handler did something that resulted in another window
being repainted, the state of the global wxDidCreatePaintDC flag got
out of sync with reality, resulting in refresh problems.
This notably happened with wxStyledTextCtrl, which generates
wxEVT_STC_UPDATEUI from its own paint handler, and so wxSTC itself
wasn't redrawn correctly if wxEVT_STC_UPDATEUI handler did anything
resulting in another repaint itself, such as calling
wxStatusBar::SetStatusText().
Fix this by replacing a single global bool with a stack of booleans,
with each window being repainted storing and removing its own flag
indicating whether a wxPaintDC was created for it in this stack.
This is sufficient for nested repaints and we really shouldn't have
any interleaved ones in any case, os it's not a problem not to support
those.
Closes#18451.
It doesn't seem worth having it when it's only used in a couple of
places in a single file, unlike GetHwnd() which is used in dozens of
places across entire wxMSW.
Under MSW allow override which subwindow will be focused for composite
windows which are implemented not as a set of wxControl (i.e. using only
Windows native controls).
Fix a regression since 23ddf26571: initial
focus was wrong in a dialog with radio button if the focused control was
disabled. This happened because m_winLastFocused didn't correspond to
the actual focus when we tried to find the next control to focus in this
case, as m_winLastFocused was changed by wxRadioButton::SetValue().
Don't change m_winLastFocused for the window which already has focus to
avoid this problem, and also because it was useless to do this anyhow.
Closes#18521.
Closes https://github.com/wxWidgets/wxWidgets/pull/1590
React to the WM_DPICHANGED event and update the size of the child windows and
the top-level window. Scale the minimum and maximum window size to the new DPI.
Only react to WM_DPICHANGED when DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is
used.
This is simpler to use than wxDisplay(window).GetPPI() which was used
instead of it so far in all ports and can be implemented more
efficiently for wxMSW.
Remove wxGetWinTLW, GetDPI already tries to get the top window.
Add MSWDoClientToScreen() and MSWDoScreenToClient() helpers and use them
with the correct HWND in DoClientToScreen() and DoScreenToClient()
overridden in wxSpinCtrl, i.e. the HWND of the "buddy" text control and
not the spin button, which is the main HWND of this control.
This notably fixes wxSpinCtrl::GetScreenPosition() which returned the
position of the spin button.
Closes https://github.com/wxWidgets/wxWidgets/pull/1454Closes#18455.
If the window has no valid font, GetFont() returns a temporary font.
Extend this font lifetime, so the HFONT remains valid till the end of
the function.
This function is a just a very thin wrapper for WM_SETFONT, but it's
still better to have it rather than write casts to WPARAM and
MAKELPARAM() in several different places.
Note that this removes the assert for font validity from
wxWindow::SetFont() which really doesn't make much sense (and if we
wanted to have it, it would be better to have it for all ports in
wxWindowBase instead) and was never triggered since more than 20 years
of its existence.
RegisterHotKey() wrongly expected to be given VK_XXX MSW virtual key
code constant, which couldn't work in portable code, so fix it to accept
WXK_XXX constants, while preserving compatibility by still accepting
VK_XXX values not clashing with them.
Information about display cached in wxDisplayFactory::m_impls and in
wxDisplayFactoryMSW::m_displays could get out of sync after removing a
display from the system, resulting in failures when calling various
wxDisplay functions later.
To fix this, reuse InvalidateCache() to invalidate the cache in
wxDisplayFactoryMSW too, making it virtual in order to allow overriding
it there. Also call InvalidateCache() from wxDisplayFactoryMSW itself
instead of doing it from wxWindow, as this works even when the
application isn't showing any windows (and also keeps all
display-related code together).
Closes https://github.com/wxWidgets/wxWidgets/pull/1246
In wxMSW, a focused wxRadioButton is always checked, which meant that
checking a wxRadioButton while focus was not in the window containing it
and later giving the focus to that window could uncheck it by giving
focus to another wxRadioButton that had had it previously.
Fix this by adding WXSetPendingFocus() to wxMSW wxWindow and calling it
from wxRadioButton::SetValue() to ensure that when the focus is
regained, it goes to the newly checked radio button and not some other
one.
This replaces the previously used, for the same purpose, wxMSW-specific
wxTopLevelWindow::SetLastFocus(), so while this solution is not exactly
pretty, it's not worse than we had before, while being more generic.
Also add a unit test checking that things work correctly in the scenario
described above.
Closes https://github.com/wxWidgets/wxWidgets/pull/1257Closes#18341.
No real changes, just make RECT (lack of) initialization before calling
GetThemeBackgroundContentRect() consistent between WM_NCCALCSIZE and
WM_NCPAINT handlers.
See https://github.com/wxWidgets/wxWidgets/pull/1141
Some custom themes apparently don't implement this function at all and
just return failure error code from it, but our code either assumed that
it never failed (when handling WM_NCPAINT) or didn't handle its failure
correctly (when handle WM_NCCALCSIZE the client rect wasn't returned at
all to the system in this case).
Fix this by just falling back to the initial rectangle in case of
failure.
The cache added in 990c8bfd73 was not
invalidated properly, meaning that wrong information was returned when
displays were [dis]connected after the application startup.
Fix this at least for MSW by invalidating the cache on receiving
WM_DISPLAYCHANGE (which means that sometimes we will do it
unnecessarily, as the change in resolution of an existing display
doesn't require cache invalidation, but this shouldn't be a big problem
in practice as the speed with which the user can change the display
resolution is not very high).
Closes https://github.com/wxWidgets/wxWidgets/pull/1090
Disabling a window before actually creating it ought to work, similarly
to hiding a window before creating it which can be used to avoid showing
the window on screen at all, even briefly. However it didn't under MSW
where the window was disabled from wxWidgets point of view, but not at
the MSW level.
Fix this by accounting for the enabled state in MSWGetStyle().
Closes#16385.
Don't use the child window of the desktop window for popup windows under
MSW, while this worked in simplest cases, it didn't allow having
functional controls inside a wxPopupWindow as e.g. wxTextCtrl didn't
accept input it at all if created as a child of such window.
Instead, switch to using a top-level window, with WS_POPUP style, and
fix the problem with the loss of activation by explicitly pretending to
still be active in the owner window when losing activation to our own
popup (thanks to Barmak Shemirani for providing this solution).
Also use an MSW-specific and much simpler implementation of detecting
when the popup should be dismissed in wxPopupTransientWindow: instead of
capturing mouse or tracking focus, just react to activation loss
directly.
Add a wxTextCtrl to the popup in samples/popup to show that editing it
works now.
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.
