When calling GetDPI() for a window which is not created itself yet and
doesn't have any valid top level parent neither, we have no choice but
to fall back on using the screen DPI, but this doesn't always work
correctly for the systems using multiple monitors with different DPIs,
so warn when this happens -- any situations when it does indicate a
potential bug that should be fixed.
See #22193.
Send these events ourselves because MSW itself doesn't generate them for
frozen windows. This makes wxMSW more consistent with the other ports.
Add unit tests to verify that the behaviour is really as expected for
both normal and frozen windows, at least under MSW -- under GTK these
events are not sent at all for the notebook pages.
Closes#19216.
This can be useful in case of unexpected window creation failure, so log
it because it doesn't cost much for something that is supposed to
practically never happen anyhow.
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
Use the same scaling function as elsewhere instead of using
ceil/floor().
Provide wxRescaleCoordWithFrom specialization for int to allow using it
with just single coordinates too.
Don't use wxClientDC in WM_NCCALCSIZE handler as creating it results in
another WM_NCCALCSIZE in wxUniv due to the call to DoSetClippingRegion()
in its wxClientDCImpl::InitDC().
Using simple WindowHDC is also a small performance gain and is all that
we need as we just need some HDC for this window and should have
probably been done like this even back in a047aff270 (Added
wxBORDER_THEME..., 2007-08-07) in which handling WM_NCCALCSIZE was
added.
Closes#19221.
The new method is currently supported in Qt, Cocoa, MSW ports (i.e. all
major ones except for wxGTK).
Keyboard example updated with a "Repeat" column.
Closes https://github.com/wxWidgets/wxWidgets/pull/2414
Catch all the exceptions when processing this event from the keyboard
hook as they must not escape from it and outside of the application.
Closes#19133.
This trivial function just allows to avoid checking if wxTheApp is not
null before calling GetTopWindow() on it.
Replace the existing "wxTheApp && wxTheApp->GetTopWindow()" calls with
wxApp::GetMainTopWindow().
No real changes.
Calling SystemParametersInfoForDpi() with LOGFONTA parameter corrupted
the stack because this function only accepts LOGFONTW, i.e. it wrote
twice as much data into the provided buffer as the caller expected.
This could be fixed by allocating a temporary wide buffer and converting
back, but this doesn't seem to be worth it, so just disable the use of
the DPI-specific function in the ANSI build.
Closes#19002.
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.
