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.
There is no need to call neither ResetBoundingBox() nor ResetClipping()
when the variables they reset had just been initialized to the same
values in the ctor initializer list.
wxSVGFileDCImpl class uses the default, i.e. inherited from wxDCImpl,
implementation of this method, but for it to work, the clipping box
coordinates stored in wxDCImpl need to be updated when the clipping
region changes or is destroyed and this wasn't done before.
Fix this now and add a unit test verifying that this indeed works.
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.
No real changes, just replace the old CppUnit test registration macros
with wxREGISTER_UNIT_TEST_WITH_TAGS() which allows to specify the tags
explicitly and use "clip" as the tag for all the tests here to allow
running all of them (and just them) by specifying "[clip]" on the test
program command line.
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.
controlBackgroundColor should be used as a background for large controls like lists etc. this corresponds to the usage of wxSYS_COLOUR_WINDOW, thanks to dkulp
Starting with macOS 10.14 Mojave, system colors can change dynamically
when the user switches between light and dark modes. Detect this by
observing the effectiveAppearance property and emit
wxSysColourChangedEvent accordingly.
See #18146.
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.
When the height of the AUI toolbar pane is higher than the wxToolbar, the extra
area shows a glitch. This happens because the paint handler never draws on this
area. Clearing the DC of the frame with the AUI background colour fixes this.
See https://github.com/wxWidgets/wxWidgets/pull/829Closes#18138
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.
Casts between incompatible function types seem to be unavoidable here,
as wglGetProcAddress() always returns generic PROC type, so just
suppress the warnings temporarily.
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".
This does the same thing but avoids gcc 8 -Wclass-memaccess warning
(harmless in this case, but potentially useful elsewhere, so it seems
better to work around rather than disable it).
The comparison could never be true as wxDEFAULT is not one of
wxBORDER_XXX values and so is not included in wxBORDER_MASK and so was
useless -- and just results in -Wtautological-compare from gcc 8.
Simply remove this check, a047aff270 added
it apparently to use themed border by default for wxVListBox, but this
was done in a better way in 28319afe55.
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.
The callback used with CreateDialogIndirect() must return INT_PTR, which
is 64 bits under Win64, not LONG, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
The callback must return LRESULT, which is 64 bits under Win64, not
int, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
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.
Don't use the deprecated since Win16 (!) and doing nothing
MakeProcInstance() and fix the signature of DDECallback() which was
actually wrong in Win64 build but the problem was hidden due to the
casts done inside and outside MakeProcInstance() before.
Remove this macro and fix the signature to actually conform to the real
callback one.
This also fixes another gcc8 -Wcast-function-type warning.
