This function was added back in a047aff270 (Added wxBORDER_THEME,
wxWindow::GetDefaultBorderForControl(), wxWindow::CanApplyThemeBorder(),
2007-08-07) but seems to have been made completely unnecessary by
dc797d8e1b (More border rationalisation. GetDefaultBorder is now mostly
defined in base class files., 2007-11-13) soon afterwards and never did
anything other than returning wxBORDER_THEME, with no explanation as to
when it might be useful to override it not to do it.
It also doesn't seem to be really used anywhere outside wxWidgets and
has never been documented, so make it non-virtual and deprecate it to
avoid confusion and simplify things.
This reverts commit cd637663c8 (Add wxWindow::MSWAfterReparent() virtual
function, 2022-10-16) and removes wxListCtrl::MSWAfterReparent() added
in ff629f3853 (Fix drawing wxListCtrl since enabling double buffering by
default, 2022-10-16) which is not used any more now.
This is sightly shorter/more convenient to use than providing all the
parameters to ::DrawThemeBackground() every time.
Similarly to ca5f244f15 (Add wxUxThemeHandle::GetColour() replacing
MSWGetThemeColour(), 2022-12-09), this is just a refactoring which
shouldn't result in any changes in behaviour.
It was unexpected that changing the window client size could change the
display the window was on and, even worse, result in further size
changes because changing the display could change the DPI scaling used.
And, worst of all, if the window wxEVT_DPI_CHANGED handler called
SetClientSize(), possibly indirectly such as via wxSizer::Fit(), this
could result in an infinite recursion when moving the window to a high
definition display located to the left of the standard definition one
(the problem didn't happen for the reciprocal display arrangement
because increasing the window size couldn't change the window display
in that case).
So ensure that the window remains on the same display it is on now, by
keeping its center position unchanged, instead of keeping the position
of its top left corner as we did before.
This is unusual, but this function may need to rescale some coordinates
and it's convenient to just call event.Scale() then.
So pass it the event that we are preparing to process to it instead of
passing it new and old DPI separately and forcing it to deal with them
itself (instead of using Scale()).
This didn't work correctly when switching from higher to lower DPI if
the frame had a status bar because this status bar still had its old,
bigger height, by the time SetClientSize() was called from the event
handler, resulting in the frame size becoming too big.
It notably resulted in having an unwanted gap between the frame contents
and the status bar if the event handler called GetSizer()->Fit().
Fix this by calling PositionStatusBar(), which also updates the status
bar height to correspond to the new DPI as a side effect, from a new
virtual MSWBeforeDPIChangedEvent() function which had to be added to
allow wxFrame to customize DPI handling.
Adding this new virtual function just for this isn't great, but the only
alternatives seem even worse.
There was no safe way to prevent wxWindow from trying to destroy the
HWND again if it had been already destroyed, for whatever reason, as
UnsubclassWin() asserted if it was called and calling SetHWND(0) before
calling it as some (but not all) existing code did, resulted in not
removing the association using the old HWND as key.
Allow to use DissociateHandle() for safely detaching HWND from the
window, without assuming that it is valid.
We need to switch to custom-drawing the box if we stop using
WS_EX_COMPOSITED as WS_EX_TRANSPARENT doesn't work correctly without it
(the background is not being painted correctly), so do this by
overriding the new MSWOnDisabledComposited() which is now called by
MSWDisableComposited() if/when it actually does disable it.
This was accidentally broken by b4dd25ee3f (Disable use of composition
for top most windows, 2022-12-25).
See #23079.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
wxOSX already does it, so do it in wxMSW too for consistency and because
it seems useful to be able to react to the same event in all cases.
Update the drawing sample to refresh its system colours scheme whenever
the theme is changed.
We don't always have a wxWindow to pass to this function, so make it
more general at the cost of being slightly more inconvenient to use.
No real changes yet.
This allows to avoid having to use casts from RECT to POINT in the rest
of the code by encapsulating this cast, and the comment explaining it,
in this function only.
No real changes.
It was pretty confusing that WindowHDC actually used client HDC and not
the (full) window one.
Also add a helper AutoHDC class releasing the DC automatically in its
dtor and use it as the common base for ScreenHDC and ClientHDC.
No real changes, this is just a renaming/refactoring.
Add a helper function wrapping ::GetThemeColor() and use it in all
places where this function was used before, as it's more convenient.
Also remove wxWindow::MSWGetThemeColour() as it was only used in a
single place and doesn't seem to present any advantages compared to
using wxUxThemeHandle new method.
There should be no changes in behaviour, this is just a refactoring.
This control doesn't seem to support dark mode natively, whichever theme
is used for it, so paint it in dark mode ourselves simply by inverting
its colours -- this is not great, but passable and better than leaving
it with a light background.
As this probably won't be the only control which will need this,
implement it at wxWindow level and allow the derived classes to opt-in
this "automatic dark mode support" by simply overriding the new
MSWShouldUseAutoDarkMode() function.
For reasons lost in the mists of time, wxRadioBox created its own radio
buttons using Win32 API directly instead of just using wxRadioButton.
Finally change this now as this significantly simplifies the code and
makes it shorter and more clear. Notably, we now can just add the
buttons to the sizer and let it manage them instead of having to do it
manually.
It also makes an ugly wxRadioBox-specific workaround in wxWindow
unnecessary. Unfortunately we still need to keep wxSubwindows stuff
because wxSlider still uses it, but this will make it easier to get rid
of it in the future, when wxSlider is changed to use wxWindows too.
This will also make the radio box appear correctly in the dark mode too,
as a nice side effect.
This style never did anything useful in wxMSW and did nothing at all in
all the other ports, so always was rather useless, but became actively
harmful not that WS_EX_COMPOSITED is used in wxMSW because using it and
WS_EX_TRANSPARENT, enabled by wxTRANSPARENT_WINDOW, together doesn't
work and results in an endless stream of WM_PAINT messages being sent to
the _siblings_ of the window with wxTRANSPARENT_WINDOW style.
Without this style drawing windows using WS_EX_COMPOSITED doesn't work
correctly as the system can't blit the window to the screen if we don't
draw it entirely, resulting in very visible redraw problems when
resizing and repositioning a window at the same time that can be seen by
just putting 2 plain wxWindow objects in a box sizer with non-zero
proportions and expand style.
For some applications turning off double buffering for individual
windows may be infeasible, so allow doing it globally using this system
option.
Note that wxAutoBufferedPaintDC still does no buffering in wxMSW now,
even when this option is set, so setting it will result in flickering in
any code using it. The solution is to use wxBufferedPaintDC directly in
the programs that use this option.
Closes#22953.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
This function will need to be used from other places too, so make it
available in the base class itself.
Also disable WS_EX_COMPOSITED for this window itself too.
Instead of calling GetMSWClassName() in wxWindow::Create() itself, just
use NULL there and interpret this as meaning to use the default wxWindow
class in CreateUsingMSWClass(), as it will allow it to distinguish
between creating generic windows and native controls.
No real changes yet.
Although fingerDistance parameter is passed as a DWORD, it is actually
a signed integer which can be negative, so handle consistently handle it
as such to ensure that zoomFactor is computed correctly, as a ratio of 2
integers.
See #22818, #22819.
Don't change the window size automatically if the application handled
wxEVT_DPI_CHANGED event to allow it to choose a better size than what is
suggested by MSW itself.
Closes#19152.
Set up popup menu bitmaps after executing wxEVT_MENU_OPEN handler, so
that any changes to the menu item bitmaps done in it are taken into
account, as this only happens when SetupBitmaps() is called.
Closes#22530.
LPARAM is a signed 64-bit type, and OBJID_CLIENT is defined as ((LONG)0xFFFFFFFC),
so converting to LPARAM will sign-extend and the comparison will always fail.
Fixed by comparing as DWORD, as the Microsoft documentation recommends.
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.
