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.
wxMemoryDC and wxScreenDC dtors were freeing a context they didn't own, potentially
causing a crash. Fixed by having the base wxWindowDC dtor free the context.
See #18566
When wxGetTBItemRect() is called on a control tool, it can cause a
TB_GETITEMRECT error message. Swap the if statements around so
wxGetTBItemRect is only called when it is needed.
Closes https://github.com/wxWidgets/wxWidgets/pull/1639
This could result in infinite recursion in wxX11, as the test for the
new size being different from the old one which was supposed to stop the
recursion, failed there in case the new size was 0: as wxX11 can't use 0
size for the window, the actual size was always different and so we kept
sending size events to the parent, which kept resizing the toolbar etc.
It could be argued that there is a bug in wxX11 and that GetSize() must
return the same value as was passed to SetSize(), even if it was 0, and
this might even be correct, in theory, but it doesn't seem worth to do
it just to accommodate this weird use case, especially because resizing
the parent from the child shouldn't be necessary in the first place and
none of wxToolBar implementations in the other ports does it.
So just remove this code completely.
Closes#18554.
Instead of repeating the same checks in several places, do it in a
single one.
Also use the smallest possible valid size (1, 1) instead of the totally
arbitrary (20, 20).
on these systems scrollbars on comboboxes are not always shown, even if the system is configured to do so, in these cases show all possible to avoid the impression of a limited subset
see https://github.com/wxWidgets/wxWidgets/pull/1534/files
Make wxEVT_MENU_HIGHLIGHT generation when there is no highlighted item
consistent across all the major ports: use wxID_NONE instead of wxID_ANY
in wxGTK and send these events, which were previously not sent at all in
this case, in wxOSX.
See https://github.com/wxWidgets/wxWidgets/pull/1637
