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
Ensure that we set m_window in case of early return from wxWindowDCImpl
ctor, so that using e.g. wxDC::GetSize() works for wxClientDC created
for windows that hadn't been realized yet.
It might be possible to avoid this early return completely as the
comment explaining why we're doing it seems to be out of date: our
SetBackground() doesn't call wxWindow::SetBackground() (and it would be
exceedingly strange if it did), but for now just the bug without
changing anything else.
Closes#18569.
Commit 70e9dbd756 has fixed#18394 but unfortunately it also caused several other issues observed e.g. in #18540. Apparently wxComboCtrl doesn't fit well to the wxCompositeWindow framework - especially when wxCB_READONLY flag is set and there is no main editor control what is problematic for wxCompositeWindow implementation. At the moment it is more pragmatic to go back to the original wxComboCtrl concept as a plain compound control to fix the regression and try to fix#18394 in an alternative way.
Closes#18540.
See #18394.
There is no reason to call ::GetMonitorInfo() all the time, e.g. just to
determine if the monitor is primary, as we can just store it entirely.
We already invalidate the information stored for all the displays
whenever anything changes, so the cached information doesn't risk
getting out of sync.
Previously, the first monitor was created instead and while it was often
also the primary one, this wasn't always the case.
In particular, this makes wxGetDisplayPPI() always return something
reasonable instead of returning (0, 0) when the first monitor is not the
primary one, as expected by plenty of code, including our own printing
sample, which divides by the values returned from wxGetDisplayPPI()
without checking if they're zero.
This is not necessarily the case at least under MSW, so while it makes
sense to do this by default in wxDisplayImpl::IsPrimary()
implementation, MSW-specific version should override it instead of being
totally unused as it was until now.
