wxIMPLEMENT_DYNAMIC/ABSTRACT_CLASS* is documented to be used with a
semicolon, though it is not mandatory.
Not touching headers yet, to avoid -pedantic warnings in user code.
See https://github.com/wxWidgets/wxWidgets/pull/2584
`AC_HELP_STRING` and `AC_CANONICAL_SYSTEM` are deprecated past autoconf
2.70+. A quick runthrough with `autoupdate` brings `wxwin.m4` in line
with this.
Closes https://github.com/wxWidgets/wxWidgets/pull/2585
Change from old `m_statusItem` API to new `[m_statusItem button]` API
because the former is now deprecated and the new one does automatic
image scaling.
Closes https://github.com/wxWidgets/wxWidgets/pull/2573
It may not be obvious how to build the tests, so add a section
explaining this to the existing file containing the instructions about
writing the tests and add a README to the tests directory itself to
increase chances that this file will be found -- hopefully anybody
interested in the tests will look at the README in the directory
containing them.
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.
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.
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.
