A number wxRIBBON_ART_TOOOL_XXX constants were not taken into account by
GetColour() and SetColour() for some reason, even though the class did
have the corresponding member colour variables.
Fix this by simply adding cases for them to the existing switch.
Closes https://github.com/wxWidgets/wxWidgets/pull/2225
If source wxImage has a mask we need to create ARGB32 Cairo surface (even
for RGB image) and based on the mask values set the alpha values to fully
transparent or retain original values.
For internal purposes wxBitmap with mask should be converted to CGImage
with alpha values only (with no mask). This is i.a. needed to assure
compatibility of wxGraphicsBitmap format with other ports where these
bitmaps are in pure ARGB format.
Remove platform-specific translations.
This is unnecessarily complicated for the single string that we
currently use this for, so just handle it specially.
Also some other minor translation-related improvements.
See https://github.com/wxWidgets/wxWidgets/pull/2213
Deal with possible size changes of a multicell (both main and inside
cells) when inserting or deleting rows or columns and, in the case of
deletion only, the disappearing of a multicell's main cell.
Closes#4238.
As shown by the fact that no other platform-specific translations were
ever added since the initial version of locale/msw/it.po added way back
in 4d931bcca0 (Translate '&Help' to '&' for italian Windows only,
2005-08-12), this is not especially useful, so just handle this
particular case specially in wxGetStockLabel() and remove support for
platform-specific translations.
This allows to simplify the makefiles and the catalog loading code as
there is no need to deal with the files in subdirectories any more.
This will allow reusing the same strings in other places.
Also use this as opportunity to add "msw" as the (preferred) synonym for
"win" for general consistency.
Because cached wxBitmap is used only to help in representing native D2D
bitmap in some operations it shouldn't be exposed directly and dedicated
methods should be implemented instead.
If source wxBitmap has both alpha channel and mask we have to apply mask
to the target GDI+ Bitmap on our own by blending its alpha values with
mask. For non-masked pixels alpha channel values will remain intact and
for masked pixels they will be set to the transparent value (0).
Currently non-bundled apps don't work on Catalina and Big Sur and what's
worse is that old the code makes it impossible to make it work in user
code.
Remove the old workaround, and replace it with an alternative one, which
seems to work under all supported macOS versions and is also used by
Tcl/Tk.
Closes https://github.com/wxWidgets/wxWidgets/pull/2216
They didn't reset the existing selection when used without Shift and
didn't extend the selection when used with Shift.
Fix both of these problems by reusing the existing logic from
GoToRelativeRow() and, added in this commit, GoToRow() which was
extracted from GoToRelativeRow().
Closes#19068.
This is not an event handler itself, so it shouldn't use "On" prefix
which is reserved, by convention, for the event handlers.
It also doesn't need wxKeyEvent, but just wxKeyboardState, so change its
signature accordingly. This will notably allow to use it from mouse
event handlers too if necessary.
No real changes.
A single line MSW wxTextCtrl created with a value too long to fit into
it continued showing the value only partially even if its size was
subsequently increased to allow the entire value to be shown.
This apparently happens because changing the native EDIT control size
doesn't affect its (horizontal) scroll offset. Moreover, there doesn't
seem to be any way to explicitly tell the control to update it neither,
except for changing its text.
So do change its text every time its width changes, as long as it is not
visible (because visible jumps in the visible text position could be an
even worse problem than the one we're trying to solve here). This fixes
the originally reported bug at the cost of a bunch of extra calls to
DoWriteText() which should hopefully be not too expensive for single
line controls that don't typically contain that much text.
Closes#18268.
