This resulted in a crash when WM_ACTIVATE was received from inside
wxWindow dtor, executed after wxTopLevelWindowMSW dtor, and passed to a
handler defined in wxTopLevelWindowMSW and using its already destroyed
members.
Perhaps we should avoid dispatching any messages when the window is
being destroyed, but it's not totally obvious that this is not going to
break something, so for now apply just this minimal fix.
Closes#18970.
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
Avoid calling GeTDPI() in font.WXAdjustToPPI(GetDPI()); invocations in
common code on platforms that don't need any adjustment (i.e. anything
other than MSW).
This fixes wxOSX crashes when GetFont() is called too early during
window creation, but is the right thing to do regardless.
Closes https://github.com/wxWidgets/wxWidgets/pull/2036Closes#18903.
This was recently broken in 3bcbc8fe8e (Implement dismissal for
unfocused wxPopupTransientWindow, 2020-07-09) as the changes in it
resulted in the popup being dismissed as soon as it was opened with a
mouse click.
Fix this by changing several things:
- Check for wxCurrentPopupWindow before processing the message, not
after, as the message handler itself could create a new popup and we
definitely don't want to dismiss it immediately after its creation.
- Check for mouse DOWN events only, not UP and DBLCLK ones, as otherwise
it might be possible that UP matching the same DOWN whose handler
showed the popup would dismiss it. As for DBLCLK, it's just
unnecessary, as it should be always preceded by a DOWN message anyhow.
- Don't dismiss the popup if the message is sent to it or one of its
children, as in this case the popup itself is supposed to deal with it
(as wxComboCtrl popup does) and we don't want to prevent it from doing
it.
With these changes both wxComboCtrl and wxTipWindow seem to work as
expected.
Closes#18844.
Popups not using wxPU_CONTAINS_CONTROLS were not automatically dismissed
at all any longer, as the only auto-dismissal mechanism related on
getting WM_ACTIVATE, which they never did, so implement a different
logic for dismissing them: do it on any change of focus and also any
mouse press (but not move and not key press neither).
This will allow not using wxPU_CONTAINS_CONTROLS for popups that don't
need focus, but still must disappear on their own.
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.
