Not sure if this is actually that useful, as this commit didn't modify
any of the still existing lines anyhow, but it seems logical to exclude
this commit, as it didn't make any real changes, but touched almost all
files.
Categories of properties can be nested so we need to search on all category
levels for the the category wxPGProperty belongs to.
And wxPGProperty removed from the alphabetical list can be a subproperty
of another property so it's parent doesn't have to be the root of the list
and we don't have to check this with assertion.
Closed#19310.
If given wxPGProperty is a subproperty of another property (its parent
is neither root nor category) it shouldn't be added directly
to the alphabetical list. It should be just added as a child property.
Stop throwing std::bad_alloc when BMP has large/negative biClrUsed by
checking that biClrUsed has a reasonable value before attempting to
allocate however much memory it indicates.
Add unit tests showing the loading such invalid bitmaps now correctly
returns an error rather than throwing an exception.
Closes https://github.com/wxWidgets/wxWidgets/pull/2583Closes#19295.
Mention that wxTE_RICH2 should be used instead of wxTE_RICH and that it
can now be turned out automatically if the initial text is too long.
See #19303.
Add a paragraph for keys where GetUnicodeKey and GetKeyCode both return
WXK_NONE, that GetRawKeyCode is platform specific, and that such keys
generate no wxEVT_CHAR event.
No real changes, but don't complicate the constants definitions
needlessly just to avoid changing the numeric value of WXK_LAUNCH_APP
constants as nobody should rely on them anyhow.
Not doing it simplifies things and allows to condense the mapping from
GDK keys to wx ones.
Add "since 3.1.0" for the constants introduced back in abd46cb99a (Add
support for multimedia keys to wxMSW and wxGTK, 2016-01-08) and also for
the new constants added in the previous commit.
Also document that WXK_LAUNCH_n keys are only generated by wxGTK.
X11 defines Xf86Launch[0-9a-f], which are then also defined as
GDK_KEY_Launch[0-9A-F].
Unfortunately, keys which are not mapped are just plain ignored and the
application is then not able to receive these keyboard events at all.
The original PR https://github.com/wxWidgets/wxWidgets/pull/157 mapped
only LaunchA/B to WXK_LAUNCH_APP1/2, this patch adds the whole range of
keys and keeps LAUNCH_A/B as aliases for WXK_LAUNCH_APP1/2
There are still plenty of X11 keys which have no WXK mapping and might be useful
for applications to act upon.
Instead of trying to remap all of them, generate a WXK_NONE key event and let
applications deal with it using GetRawKeyCode() if appropriate.
This is another correction to the changes of 62c3d921b2 (Check that all
windows in a sizer use associated window as parent, 2021-10-20): we need
to restrict the part of this check in wxSizer::SetContainingWindow() to
the case when this function argument is non-null, otherwise the check
would always fail.
Notice that it is perfectly valid to call SetContainingWindow(NULL) and
wxWrapSizer does it for every re-layout, for example.
This commit is best viewed ignoring whitespace-only changes.
See #19308.
The check added in 62c3d921b2 (Check that all windows in a sizer use
associated window as parent, 2021-10-20) didn't work correctly when
using wxStaticBoxSizer, as the windows in this sizer are grandchildren
(or possibly even further descendants, in case of nested sizers) of the
window that the sizer is associated with, with the static box being the
immediate parent.
Relax the check to account for this and to avoid triggering for any use
of wxStaticBoxSizer.
Closes#19308.
While wxMSW now turns this style on automatically if necessary, it's
still better to avoid the failure during the initial control creation,
so enable wxTE_RICH2 from the beginning in wxTextEntryDialog, where it
shouldn't result in any incompatibilities.
When creating a wxTextCtrl with the initial text which is too long to
fit into a plain EDIT, automatically create RICHEDIT instead.
This is not perfect, e.g. it still doesn't make calling SetValue() with
long text later work, but it seems to still be preferable to failing to
create the window completely, which results in many other more difficult
to diagnose problems later.
This can be useful in case of unexpected window creation failure, so log
it because it doesn't cost much for something that is supposed to
practically never happen anyhow.
This was broken in b102afc316 (CMake: Don't include generator expression in
wxPLATFORM_LIB_DIR, 2021-10-17).
And for clarity, always add a '/' after directories.
Closes#19305
These functions used to work in any mode until the changes of 02509cbc39
(Refactor wxGridSelection to store selection as blocks only, 2020-03-03)
and should continue to do so, if only for compatibility.
Temporarily reset the m_selection pointer itself instead of clearing the
selection, this is much more efficient, especially for big grids, and
also more correct, as the old code simply lost the original selection in
non-block selection modes.
The changes of b20552116c (Allow wxBitmapBundle to specify its preferred
bitmap size, 2021-10-19) resulted in never rescaling the bitmaps in
standard size in high DPI at all, which isn't the right thing to do: by
default, i.e. if just a single bitmap is specified, we should scale it
up as necessary in order to show the UI elements in the correct sizes.
Define CopyFromIcon() directly in wxBitmapBase for the non-MSW ports, as
it was implemented exactly in the same way in all ports using this class
anyhow.
This means this function is not virtual any longer, but this shouldn't
be a problem as it was never supposed to be overridden in application
code and this couldn't be done with wxMSW, where it never was virtual in
the first place, anyhow.
No real changes, just a simplification.
Just use the same object, as wxIcon is the same thing as wxBitmap
anyhow, instead of re-creating another wxBitmap which can be subtly
different from the original one.
Notably, converting an icon with default scale factor of 1 to bitmap
when using a high DPI display resulted in a bitmap with the same
physical size but scale factor of 2, as wxOSXGetImageScaleFactor()
returned 2 in this case, i.e. changed the logical bitmap size.
This couldn't be anything other than a bug, so fix this and, at the same
time, simplify the code and make it consistent with the other ports.
We must call SetInitialSize() in Create() in order to take the size
argument passed to ctor/Create() into account -- it was completely
ignored previously.
But calling SetBitmap() must not change the initial size, as it can also
be done later, so just change the current size there instead (which is
consistent with wxMSW version and original behaviour, so keep it like
this, even though it's not totally clear if all ports do it).
Remove the now unused wxGenericStaticBitmap::GetBitmapSize().
Instead of defining them, slightly differently, in all the non-MSW
ports, define them once in wxStaticBitmapBase.
No real changes, this is just a simplification.
