Rewrite CreateLayout() using SetVirtualSize() to avoid trying to detect
whether the vertical scrollbar is shown manually. This is simpler and
avoids the problem of entering infinite loop if the scrollbar size used
by this function (based on wxSystemSettings::GetMetric(wxSYS_VSCROLL_X))
wasn't correct, as used to be the case for wxGTK until the recent commit
900752b152 and might still be the case in
the other ports.
Closes#18141.
This reverts commit e771b7e4ac.
Don't always pass WM_SYSKEYDOWN to the system for processing as this can
be undesirable: e.g. inside a dialog, any Alt-X key presses with X not
being a mnemonic character result in a beep from IsDialogMessage().
Handle events for the system keys in the same way as for the normal
ones, i.e. let the system process them only if they're not handled by
the application.
This is incompatible with the previous wxMSW behaviour, but compatible
with the other ports and makes more sense, so it seems to be worth it,
on balance.
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.
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.
