Replace direct use of wxImageList with the use of wxWithImages, which
will make adding support for using wxBitmapBundle later simpler.
In fact, this already somewhat simplifies the code by removing the need
to manually take care of m_ownsImageListXXX flags.
Use HAS_GENERIC_TREECTRL for testing whether we're actually using it or
not instead of checking for USE_GENERIC_TREECTRL and then port names
with a native control, which was done inconsistently, as it included
wxQt in one place, but not the other one.
Also avoid repeating CreateButtonsImageList() declaration twice, as this
resulted in having unbalanced curly braces in this file, which was just
unpleasant.
No real changes.
Just pretend that the images themselves have changed, this should be
enough to recreate wxImageList from the bundle using the new scale
factor in UpdateImageListIfNecessary().
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.
Such thread names can be shown by some debuggers, and depending on
the OS and compiler versions used, they can be visible in process
lists and crash dumps.
Co-authored-by: PB <PBforDev@gmail.com>
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.
Edge does not support the about: URL using it in the test resulted
in various problems. Just use about:blank for now as the edge backend
does not merge them for the history checks.
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 new function will allow selecting the bitmap of the most suitable
size and automatically react to DPI scale changes (although this hasn't
been implemented yet) in all controls using image lists.
For now, only wxNotebook in wxMSW has been updated to work with it, the
other classes and ports will be updated to override OnImagesChanged()
instead of SetImageList() later.
Also update the notebook sample to use SetImages() rather than
SetImageList() -- which means that it doesn't show the icons any longer
in non-MSW ports, which haven't been updated yet.
Move the code for determining the size preferred by a bunch of bitmap
bundles from wxToolBar to wxBitmapBundle itself to allow reusing it from
other classes.
No real changes, this is just a refactoring.
This commit is best viewed with --color-moved git option.
These functions allow avoiding using wxImageList explicitly in a couple
of places.
No real changes, this just prepares for adding new API not based on
wxImageList.
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.
