This breaks Mac build by default and shouldn't be done. In fact, Cairo
should be used only optionally under MSW and Mac, where it's not always
needed, so add a new configure option to request it.
There is absolutely no good reason to do it and it resulted in
silently truncating all the string formatted using "%s" to their first
65535 characters when using our wxPrintf() implementation.
Closes#18586.
The code in the example showing how to create a new event class
confusingly used several names for the event type.
Fix this and also prefix the name of the new event type with "EVT_" to
match wxWidgets convention for naming event types.
Also explicitly mark the parts that are not needed if only Bind() is
used for event handling.
Closes https://github.com/wxWidgets/wxWidgets/pull/1586
A just created control shouldn't be considered modified, so reset its
modified state in Create().
And add a unit test checking that IsModified() really behaves as
expected.
Closes https://github.com/wxWidgets/wxWidgets/pull/1652
We don't need it any more, just define individual tests as independent
test cases.
This required using some other pointer instead of "this" in one of the
tests, but it doesn't really matter which pointer we use there anyhow.
No real changes.
Don't scale, or even copy, the font object unnecessarily in the common
case when the font scaling factor is 1.0 anyhow.
No real changes, just make the code slightly more efficient and also a
bit more concise after the changes of the previous commit.
Respect the system font scaling parameter (e.g. "Fonts->Scaling Factor"
in Gnome Tweaks, "Force font DPI" in KDE System Settings or
GDK_DPI_SCALE environment variable) when drawing text using wxFont.
This ensures that generic widgets have their text scaled appropriately
to be consistent with native widgets.
Closes https://github.com/wxWidgets/wxWidgets/pull/1635
This is unnecessary, this header should always be available, so it was a
waste of time to check for it at best and, actually, this broke the
Cygwin build under AppVeyor as configure didn't find the header somehow,
even if compiling the code using it works perfectly well.
Actually allow using wxWebVieWIE-specific methods for setting the
emulation level.
Make it possible to include wx/msw/webvieW_ie.h by removing inclusion of
the private headers from it, which was in turn achieved by moving all
the implementation details into a private class.
See https://github.com/wxWidgets/wxWidgets/pull/1647
Trailing spaces and tabs are invisible, so the string shouldn't be
truncated (possibly losing some printable characters that could have
been displayed) just in order to show "..." instead of them.
Verify that we have exactly as many offsets as expected, both in the
case when the string terminates with a (lone) ampersand and when it
doesn't, instead of checking that it's one or the other without caring
in which case we're.
No real changes, but this seems slightly cleaner and avoids questions
about the expression "s.length() - 1" when the string is empty.
The old code didn't work correctly in the presence of TABs in the string
(without wxELLIPSIZE_FLAGS_EXPAND_TABS being used), as their width is
elastic and so simply subtracting the width of the ampersands didn't
work in this case and could result in ellipsized string being longer
than the maximum available width.
Fix this by using a different approach and computing the widths of the
actually shown string and then just inserting extra entries into the
array of widths to match the invisible ampersands positions.
Previously we added the extent of the text to the preferred size of a
spin button with 0 digits, but this didn't account for the fact that the
control still reserved enough space for 3 digits in this case, and so
the returned size was always too big than the required size by the width
needed to show 3 digits.
Fix this by directly asking for the size required to show the number of
digits corresponding to the given text size.
Note that ideal would be to provide GTK API at wx level directly, i.e.
allow to just specify the number of digits instead of the text extent.
But we still need to fix the already existing GetSizeFromTextSize()
anyhow, so do this for now.
See #18568.
Ensure that the entry is always (just) big enough to show any value
valid in this spin control.
This also ensures that GetBestSize() doesn't need to be overridden to
use GetSizeFromTextSize() any longer as the best size will be determined
correctly by GTK itself.
The full size includes the borders and the return value of this function
might not actually be fully visible if we use it, as it can fit into the
full width but not the client width. And at least under MSW this
resulted in the ellipsized label being wrapped, which was completely
unexpected, especially if the second line of the control was not visible
at all as it seemed that the last word simply disappeared.
Closes#18573.
For GTK2, get the "inner border" the same way GTK does it. And for GTK3,
provide an actual implementation. Also, don't return a wxPoint for a size.
See #18567
If wxEVT_PAINT handler did something that resulted in another window
being repainted, the state of the global wxDidCreatePaintDC flag got
out of sync with reality, resulting in refresh problems.
This notably happened with wxStyledTextCtrl, which generates
wxEVT_STC_UPDATEUI from its own paint handler, and so wxSTC itself
wasn't redrawn correctly if wxEVT_STC_UPDATEUI handler did anything
resulting in another repaint itself, such as calling
wxStatusBar::SetStatusText().
Fix this by replacing a single global bool with a stack of booleans,
with each window being repainted storing and removing its own flag
indicating whether a wxPaintDC was created for it in this stack.
This is sufficient for nested repaints and we really shouldn't have
any interleaved ones in any case, os it's not a problem not to support
those.
Closes#18451.
Under wxOSX bitmap pixel values are already premultiplied so bitmap data
can be copied to the target surface directly.
Since 992b594c wxMask bitmap colours are no longer inverted and have
the same meaning as for another ports.
wxAlphaPixelData can be only used to access pixel data in 32 bpp bitmaps.
Also, because bitmaps can have both alpha values and mask, the mask should
be applied to the created surface even if alpha channel exists. Masked
pixels become fully transparent and unmasked pixels should retain original
alpha values.
Closes#18570.
This was broken by 048b7f44ec which wasn't
supposed to change anything, but did because it effectively replaced the
call to wxDC::GetPaperRect() with wxDC::GetSize() when initializing
wxPrintout::m_paperRectPixels, and while GetPaperRect() is the same as
GetSize() in wxGTK, it returns the rectangle including non-printable
margins in wxMSW and wxOSX, and must be used here instead.
Closes#18565.
Closes https://github.com/wxWidgets/wxWidgets/pull/1640
