Size should include border and padding. Margin values seem to be for a checkbox with text
label, so don't include margin. Check mark should be drawn inside border and padding.
Don't return RGB values if colour is not solid
and hence cannot be represented with these values.
Non-solid colour should be reported as an unknown
RGB value, e.g. '??????'.
Closes#18596.
Just use hardcoded 2px overlap between the text control and the spin
buttons, as it doesn't seem to depend on the DPI and works in both LTR
and RTL modes, unlike the existing code, which claimed to work but
actually didn't.
Closes https://github.com/wxWidgets/wxWidgets/pull/1660
Replace a few occurrences of
type var
= value;
with
type var =
value;
which is used much more widely in wx sources for consistency.
Also get rid of a couple of such lines, when it could be done easily.
No real changes.
Fix bug with not being able to update wxTaskBarIcon under MSW after a
DPI scale change or [dis]connection of another monitor using different
DPI: this resulted in "TaskbarCreated" message being sent by the system,
which we handled by trying to create the taskbar icon again. However in
this case, recreating it failed, presumably because it still existed, as
modifying the existing icon still worked.
Change the handle of "TaskbarCreated" to try both adding and updating
the icon, as it seems that we can't be sure whether we still have it or
not when we get this message.
Refactor the existing code to specify the operation to perform when
calling the new DoSetIcon(). This actually makes things slightly simpler
for it, as it doesn't need to update m_iconAdded inside it any more.
Closes#18588.
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
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.
