When the original wxGCC_WARNING_SUPPRESS was added, clang understood all
gcc warnings, so it made sense to also apply it when building with
clang, but recent gcc versions have added warnings not available in
clang any more, so we now need a macro for disabling warning the
warnings for gcc only.
Perhaps we should rename the existing wxGCC_XXX macros to use
wxGCC_OR_CLANG prefix.
Due to what looks like a bug, gcc 9.3.0 gives the following incomplete
error message without it:
include/wx/graphics.h:278:7: error: but
‘wxGraphicsGradientStop::wxGraphicsGradientStop(wxGraphicsGradientStop&&)’
does not throw; perhaps it should be declared ‘noexcept’
[-Werror=noexcept]
(without any other diagnostics).
gcc 9 gives -Wnoexcept for these operators and, apparently, not making
them noexcept prevents some optimizations in the standard library
implementation of unordered_foo<>, so do add it.
Unlike the later versions, g++ 4.8 produces a -Wshadow when the name of
a parameter is the same of the name of a method, so rename the (private)
parameters to avoid this.
As wx headers are included from user applications which may compile with
higher warning level than wx itself, try to check headers compilation
with almost all of gcc warning flags turned on.
This notably should prevent the headers from becoming uncompilable with
-pedantic again in the future.
If the same function used any of macros from wxCHECK() family more than
once, wxDummyCheckStruct was redeclared, resulting in -Wshadow warnings
from gcc.
Fix this by using unique names for the dummy macro.
Fix a regression introduced in c924ecb10a (Suppress -Wsuggest-override
warnings in user code for gcc too, 2020-07-27) and rearrange the macro
to make sure a semicolon is necessary after it.
Closes#18901.
Also add GlobalPtrLock::GetSize() and use it instead of calling
GetSizeFromBuffer() as it's more direct and doesn't require the use of
::GlobalHandle().
Using ::HeapSize() on a global pointer is wrong, and even though it
somehow still works under "genuine" MSW, it crashes under Wine.
Fix this by using ::GlobalSize() instead, which is the right function to
use with this kind of pointer.
Thanks to Damjan Jovanovic for the analysis of the problem in Wine
bugzilla (see https://bugs.winehq.org/show_bug.cgi?id=38924#c10).
Closes#18887.
Preserve the ampersands in the string, which is consistent with wxGTK
behaviour and less surprising than the default behaviour, which creates
mnemonics in the tooltips that are, of course, perfectly useless, as
they can't be activated from keyboard anyhow.
Turn on TTS_NOPREFIX, which is already used by wxToolTip, to fix this.
Closes#18899.
This used to be broken, see #18898, and now that it is fixed by
5a70051c7e (Avoid assertion failure in wxButton with bitmap and empty
label, see #18898, 2020-08-21) add a unit test so that it stays fixed.
Use the same art provider for a floating frame detached from an existing
wxAuiManager as was used by the original wxAuiManager itself, to ensure
that the appearance of this frame is consistent with the appearance of
its parent.
Implementing this required adding wxAuiDockArt::Clone() to allow copying
it in the new frame and this patch also adds GetAuiManager() to
wxAuiFloatingFrame, similar to the existing method in wxAuiNotebook, in
order to allow changing the dock art from the application code if
desired.
Closes https://github.com/wxWidgets/wxWidgets/pull/2022Closes#18882.
Make the wxART_* constants const wxStrings to improve compatibility with
pre-3.1.4 code and, in particular, allow taking the address of these
constants.
See https://github.com/wxWidgets/wxWidgets/pull/1996
This can take multiple seconds in big lists, meanwhile the UI is frozen at the
display border. Adjust the font of the attribute to the DPI when it is used for
drawing.
This is not needed any longer after the changes of the last commit.
Note that the (still existent) public wxGetDisplaySizeMM() didn't use
this function, but used PPI instead.
Don't try computing the PPI ourselves from the physical size and the
number of pixels, this doesn't work and nobody else does it like this.
Just assume that we're using standard PPI by default and use
toolkit-specific functions for the platforms with support for high DPI.
