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.
Ensure that another TLW is active before calling ShowWithoutActivating()
as otherwise the newly shown window would be considered active, even if
it actually isn't, because it contains the current focus.
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
After the recent dynamic array macros refactoring, there was no
implementation of wxBaseArray any more and only wxArrayString-related
code remained in this file, so just move the latter to arrstr.cpp, where
it should have been put from the beginning (except that this code
probably predates arrstr.cpp addition), and remove the old file
entirely.
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.
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
