No real changes, just rename the members to use the standard prefix
which is more consistent with the rest of wxWidgets and also allows to
avoid both the hacks with "foo_" names for the arguments of some
functions that were used to avoid the conflicts with member "foo" and
at least one remaining shadowing warning for "exitcode".
__clang_analyzer__ is a constant that only is defined during analyze build, this helps avoiding false positives as long as there is no specific way to silence analyzer messages
Both attributes are used only in wxBoolProperty and wxFlagsProperty to set respective internal flags and don't have to be stored in the property's attribute store.
Provide a way to retrieve the name of the current system appearance
(mostly for diagnostic purposes) and check if it uses predominantly dark
colours.
Currently this class has a non-trivial (but still very simple)
implementation under macOS only and simply checks whether the default
text colour is brighter than the default background colour under the
other platforms, but other platform-specific implementations could be
added later.
Also update the drawing sample "system colours" page to show the system
appearance as well.
The advantage of using this compiler builtin instead of our own platform
checks is that the compiler will warn us (if -Wunguarded-availability is
turned on for APIs introduced before 10.13 or by default for later ones)
if a check is forgotten, which is not the case for the manual checks.
Update the code to use WX_IS_MACOS_AVAILABLE() macro, which expands to
__builtin_available() when supported, and also use API_AVAILABLE() where
it makes sense to avoid having too many checks.
Commit 58d4b0e209 introduced a regression:
if a previous popup still existed when the new one was shown, dismissing
the second popup would result in the owner window losing its "active"
appearance.
This was due to the fact that ::GetActiveWindow() still returned the
former popup when it was about to be dismissed, so it was too early to
call it in WM_NCACTIVATE handler. Do it now in DismissOnDeactivate()
itself which is both simpler and more correct.
There were at least 2 problems when showing a transient popup while
another one was already shown in wxMSW, as could be seen by showing
several wxRichToolTips in a row from a timer event handler, for example:
First problem was that wxCurrentPopupWindow was incorrectly reset in
this case by the old popup window when it was hidden, even though it
should have been remaining set to the new popup window. Fix this by
checking that we only reset wxCurrentPopupWindow when hiding the popup
if it still points to this popup, but not if it has been changed to
point to another one in the meanwhile.
Second problem was more mysterious and resulted in simply not receiving
the activation events for the new popup when showing it resulted in
hiding the previous one. The working hypothesis is that hiding a window,
which changes activation on its own, from WM_NCACTIVATE handler in our
code confused ShowWindow(), which handles switching activation, which
didn't expect this to happen, so the fix is to avoid doing anything
immediately from this handler and wait until the next idle event to do
it instead.
These fixes ensure that showing several popups in a row works correctly,
i.e. hides the previous popup when a new one is shown and also keeps the
parent window appearing active during all the time and deactivates it if
the focus switches to another top level window at the end.
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
This works around gcc -Wredundant-decls warning that was given (if
explicitly enabled) when both wx/vector.h and wx/utils.h were included.
The workaround is ugly, but it doesn't seem worth it to introduce a
separate wx/qsort.h header just for this single function, which seems to
be the only other way to fix this.
Closes https://github.com/wxWidgets/wxWidgets/pull/1271
In this case wx-specific RTTI is used and GetWxTypeId() method was
overridden without using wxOVERRIDE, which resulted in dozens of
warnings for each translation unit.
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.
OnValidationFailure() in derived class wxEnumProperty has the same implementation (empty body) as the implementation in the base class wxPGProperty so overriding this function in derived class is not necessary.
- Remove duplicate wxConsoleAppTraits::CreateEventLoop()
It's already defined for Unix as well as Windows
- Remove wxEventLoop AddSourceForFD() "override"
the base version is static and therefore clearly not meant to be overridden
Encapsulate the logic for deciding whether we should show the labels for
the embedded controls or not in a small helper function, to make it
simpler to change it in the future if needed and also to have a single
place to explain why do we do what we do now.
No real changes.
