Checking for the exact match of __GXX_ABI_VERSION created more problems
(including for both Fedora and Debian packagers, see
https://github.com/wxWidgets/wxWidgets/pull/828) than it solved
(approximately 0), so relax it and assume that future g++ versions will
remain broadly compatible with the current ABI, which seems like a safe
assumption so far.
It's not really clear if there is any value in having this ABI check at
all, or if we should remove CheckBuildOptions() and all the code calling
it entirely, as it seems that there is no way to trigger this check
during run-time without getting a link error first. But keep it for now,
just because it's simpler to keep it than to remove it.
Just test m_blockEvents directly, there doesn't seem to be any gain in
using an accessor here.
Also test it only once instead of doing it twice in
MacHandleSelectionChange().
Prevents deselecting the selected item in single-selection listbox.
Also generate correct events in the multi-selection case by reusing the
existing wxListBoxBase::CalcAndSendEvent() method.
Closes#15603.
Passing an empty std::vector<wxString> to Append() or Insert() methods
of any wxItemContainer-derived classes, such as e.g. wxComboBox,
resulted in undefined behaviour due to accessing the first element of an
empty vector.
Fix this by avoiding using it when the vector is empty.
For some reason lost in the depths of time (but probably just a typo)
(but probably just a typo) (but probably just a typo) (but probably just
a typo), SetItem() overload taking the column index returned "long" and
not "bool", even though the actual return value was always "true" or
"false" (or even just always "true" in the case of the generic version).
Change it to return "bool" for consistency with the other overload and
because this just makes more sense and shouldn't break any existing code
due to the implicit conversions between bool and long.
Also document the return value meaning.
Closes#18153.
When wxColourDialog is shown, any changes to the colour selected in it
apparently result in broadcast messages to all currently visible text
controls, which was unexpected.
Block the changeColor: message to prevent this from happening.
Closes https://github.com/wxWidgets/wxWidgets/pull/830
Since the changes of 6ae7aa4443, the
windows were shown when their geometry was restored as a side effect of
calling ::SetWindowPlacement(). This was unexpected and resulted in
flicker on startup, so fix this by explicitly passing SW_HIDE to
SetWindowPlacement() if the window is currently hidden and storing the
real show command inside wxTLW itself, where it will be used when it's
finally shown.
This single field replaces m_iconized and m_maximizeOnShow which were
not really independent and will make it simpler to schedule either
maximizing or maximizing the window later, when it can't be done
immediately because the window is hidden, in the following commit.
Add wxHtmlEasyPrinting::SetPromptMode() to allow suppressing the
"prompt" shown by wxPrinter::Print() when it's called from this class
code.
Closes https://github.com/wxWidgets/wxWidgets/pull/838
This class doesn't have any non-inline methods and so doesn't need to be
exported from the DLL.
This also avoids warnings in MSVC DLL build about using non
dll-interface class wxArrayTreeItemIdsBase as base for dll-interface
class wxArrayTreeItemIds (C4275).
The new method returns a boolean flag which indicates whether there is
any clipping region or not and so is preferable to using the old one and
checking its return value to determine this, which can't be done
reliably.
No real changes, just call wxDCImpl::DestroyClippingRegion() from
the overridden versions in the derived classes instead of calling
ResetClipping(): this makes the code more clear as it follows the usual
pattern of the derived class doing something first and then forwarding
to the base class.
Also, as ResetClipping() is not really useful, add a comment documenting
that it shouldn't be used in the new code.
Determining whether there is an actual clipping region or not is not
that simple, as shown by the recent problems in wxDCClipper code, so
return a boolean value indicating this from GetClippingBox() directly,
instead of requiring the caller to find it out on their own.
This simplifies wxDCClipper code, as well as any other code calling
GetClippingBox(), at the price of some extra complexity in wxDCImpl
itself, which seems to be worth it.
wxDC::GetClippingBox() is actually supposed to return a rectangle equal
to the total wxDC area and not an empty rectangle if there is no
clipping box at all, so avoid restoring the old clipping region
unnecessarily in this case too: even if it should be harmless, it's
still unnecessarily inefficient and, in practice, this is not really
harmless neither as wxPdfDC (from the third party wxPdfDocument library)
doesn't handle having a clipping region set when adding a new page
correctly and so using wxDCClipper broke PDF generation.
This fixes another fallout from 2a8c290e0d
See #13834.
The system color functions depend on the current appearance, this is not automatically set to the effective appearance (that can be changed during runtime via the system preferences), added a helper class to make sure the correct version is used for retrieval.
While Windows headers compile without warnings at maximal warning level,
they still contain some warnings which are disabled by default, but can
be enabled explicitly, such as C4668.
Make life simpler for the user code doing this by avoiding giving these
warnings from the Platform SDK headers as it doesn't cost much to do
this from wxMSW itself, while doing it from the user code is nontrivial.
Don't cast function pointers of incompatible types, this resulted in gcc
8 -Wcast-function-type warnings and could hide real errors.
To fix this, overload wxBaseArray::Sort() to accept either the "legacy"
sort function compatible with qsort() or a function compatible with
std::sort(), as it seems both variants could be used before. Also make
the type of the latter function customizable via a new optional Sorter
template parameter in wxBaseArray in order to allow wxSortedArrayString
to specify its own variant of it, taking (const) references instead of
values.
This complicates things, but should preserve compatibility while being
type-safe and, also, allows to simplify _WX_DEFINE_SORTED_TYPEARRAY_2 by
not passing the sort function signature to it any more.
Use templates to implement the legacy dynamic array classes as much as
possible instead of doing it in macros.
This makes the code much more maintainable and readable as well as
easier to debug.
It also allows to avoid casts between function pointers of incompatible
types, which triggered many -Wcast-function-type warnings from g++ 8.
Don't cast function pointers of incompatible types, this resulted in gcc
8 -Wcast-function-type warnings and could hide real errors.
Use normal, taking elements by value, sort function for in wxBaseArray
methods used by the sorted arrays only and provide Sort() overloads for
both this sort function variant and the compatible with qsort() one
taking pointers to the elements.
Suppress the warnings about formally incorrect but working in practice
cast from an event handler taking an object of a class derived from
wxEvent to wxEventFunction, i.e. a handler taking just wxEvent itself.
These warnings are unavoidable in a few places, and testing for gcc
version and suppressing them is too verbose, so define helper macros
making it a bit less painful.
BucketFromNode typedef must be defined as a function returning size_t,
as GetBucketForNode() method in the classes generated by hash map macros
does, to avoid warnings about bad function pointer casts in Win64 build,
where size_t is not the same thing as "unsigned long".
By now all compilers/SDKs should hopefully have {Get,Set}WindowLongPtr()
and GWLP_XXX constants, so there is no reason to keep separate, and
differing by return type in wxGetWindowProc() case (oversight?),
versions of these functions for Win32 and Win64 builds.
Combine them in a single version appropriate for both cases.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
This parameter wasn't used anyhow and casting wxWndProc or m_oldWndProc
to WXFARPROC just resulted in gcc8 -Wcast-function-type warnings.
Get rid of them by not passing the window proc to this function at all.
Put the code implementing object arrays, i.e. arrays owning pointers to
the objects, into wxBaseObjectArray<> instead of _WX_DECLARE_OBJARRAY
macro.
Also simplify WX_DEFINE_OBJARRAY() by leaving only the definitions of
functions creating and destroying the objects in it (they have to be
there and not in the template itself to allow using template with
incomplete classes).
Add wxBaseSortedArray<> template instead of putting all the code inside
_WX_DEFINE_SORTED_TYPEARRAY_2 macro.
There should be no changes, but the code is now easier to read and
modify.
Dramatically simplify dynamic array macros by keeping only the
implementation previously used in wxUSE_STD_CONTAINERS case and dropping
the other one, as we can use the std::vector-based implementation on top
of our own wxVector<>, which is available whether wxUSE_STD_CONTAINERS
is 0 or 1.
This allows to get rid of tons of ugly macro-based code without breaking
compatibility.
