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
This can be useful to implement custom handling of WM_COMMAND for the
popup menus, so make this function virtual and document it to indicate
that it is now part of the public API.
Closes https://github.com/wxWidgets/wxWidgets/pull/2170
Only disable using the system libraries when a built-in version is
available, otherwise still use the system library as this seems more
useful than disabling the use of only some system libraries (liblzma and
libcurl), while still possibly depending on dozens more via GTK.
Update the documentation and remove the now unnecessary --with-libcurl
from the CI script.
Closes https://github.com/wxWidgets/wxWidgets/pull/2208
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.
Use /Zc:throwingNew option for the compilers supporting it instead of
defaulting to compatible behaviour, which assumes that operator new can
return NULL on allocation failure, that we don't need, at least in the
release builds.
This is also slightly more efficient as it allows the compiler to avoid
generating null checks after calling new.
Closes#19069.
Don't add both a directory and its subdirectories to SAMPLES_SUBDIRS as
this can result in 2 sub-makes building in the same directory in
parallel: one make process recursing into sub-subdirectory from the
subdirectory and another one running directly inside it. This notably
results in recurring failures in GitHub Actions CI builds.
We still need to create makefile.in in the subdirectories containing
other samples, so add a separate SAMPLES_SUBTREES variable and use it to
collect such directories, instead of putting them into SAMPLES_SUBDIRS
itself.
Somehow ASAN reports a memory leak in this test:
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fc54732ebc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7fc546685cb8 in g_malloc ../../../glib/gmem.c:102
#2 0x7fc543a49b41 in _gtk_rbtree_new ../../../../gtk/gtkrbtree.c:333
#3 0x7fc543b0831a in gtk_tree_view_real_expand_row ../../../../gtk/gtktreeview.c:12922
#4 0x7fc543b1087a in gtk_tree_view_expand_row ../../../../gtk/gtktreeview.c:12983
#5 0x7fc5453ba344 in wxDataViewCtrl::DoExpand(wxDataViewItem const&, bool) src/gtk/dataview.cpp:5013
#6 0x7fc5458e5a0e in wxDataViewCtrlBase::ExpandAncestors(wxDataViewItem const&) src/common/datavcmn.cpp:1297
#7 0x7fc5453bce08 in wxDataViewCtrl::SetSelections(wxDataViewItemArray const&) src/gtk/dataview.cpp:5228
#8 0x5557834c5745 in test controls/dataviewctrltest.cpp:178
#9 0x5557834d688c in invoke ../3rdparty/catch/include/internal/catch_test_registry.hpp:25
#10 0x5557831434ef in Catch::TestCase::invoke() const ../3rdparty/catch/include/internal/catch_test_case_info.hpp:176
#11 0x55578317f10f in Catch::RunContext::invokeActiveTestCase() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bc10f)
#12 0x55578317e9dd in Catch::RunContext::runCurrentTest(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bb9dd)
#13 0x55578317b5cc in Catch::RunContext::runTest(Catch::TestCase const&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1b85cc)
#14 0x55578313c64a in Catch::runTests(Catch::Ptr<Catch::Config> const&) ../3rdparty/catch/include/internal/../catch_session.hpp:82
#15 0x555783180e05 in Catch::Session::runInternal() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bde05)
#16 0x555783180931 in Catch::Session::run() (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bd931)
#17 0x555783180899 in Catch::Session::run(int, char const* const*) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1bd899)
#18 0x55578315719a in TestApp::RunTests() test.cpp:635
#19 0x5557831a63c7 in TestApp::OnIdle(wxIdleEvent&) (/home/runner/work/wxWidgets/wxWidgets/tests/test_gui+0x1e33c7)
#20 0x7fc5446bbbfe in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const src/common/appbase.cpp:654
#21 0x7fc5446bbdba in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const src/common/appbase.cpp:666
#22 0x7fc5449b29dd in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) src/common/event.cpp:1416
#23 0x7fc5449b47f4 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) src/common/event.cpp:1888
#24 0x7fc5449b32be in wxEvtHandler::TryHereOnly(wxEvent&) src/common/event.cpp:1609
#25 0x7fc5449b70a7 in wxEvtHandler::TryBeforeAndHere(wxEvent&) include/wx/event.h:3949
#26 0x7fc5449b2f72 in wxEvtHandler::ProcessEventLocally(wxEvent&) src/common/event.cpp:1546
#27 0x7fc5449b2ec5 in wxEvtHandler::ProcessEvent(wxEvent&) src/common/event.cpp:1519
#28 0x555783156ef7 in TestApp::ProcessEvent(wxEvent&) test.cpp:615
#29 0x7fc5446badef in wxAppConsoleBase::ProcessIdle() src/common/appbase.cpp:431
but only if another wxDataViewCtrl test runs after it, i.e. there is no
leak when running just this test on its own.
This doesn't seem to make sense, as wxDataViewCtrl, and hence
GtkTreeView, is destroyed at the end of the test and it shouldn't be
possible for a test running later to affect the presence or absence of a
memory leak in it, so it might be a LeakSanitizer bug, but this doesn't
help actually getting rid of it.
The only other possibility would be to suppress this leak, but this
doesn't seem ideal, as we could suppress some other real leak too, so
for now just skip this test when using ASAN.
This makes things much, much slower, but unfortunately seems to be the
only way to avoid memory leak reports when running the tests as without
it the suppression is not used because the stack is truncated, i.e. we
only see
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f0968253bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7f09675aacb8 in g_malloc ../../../glib/gmem.c:102
in the output when the actual stack, seen with fast_unwind_on_malloc=0, is
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f12b913bbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7f12b8496cd8 in g_malloc ../../../glib/gmem.c:102
#2 0x7f12b84b0f93 in g_strdup ../../../glib/gstrfuncs.c:363
#3 0x7f12b49adb2a in atk_bridge_adaptor_init ../atk-adaptor/bridge.c:1039
#4 0x7f12b566d753 in _gtk_accessibility_init ../../../../gtk/a11y/gtkaccessibility.c:992
#5 0x7f12b5821cfc in default_display_notify_cb ../../../../gtk/gtkmain.c:714
#6 0x7f12b5589801 in g_closure_invoke ../../../gobject/gclosure.c:810
#7 0x7f12b559d813 in signal_emit_unlocked_R ../../../gobject/gsignal.c:3742
#8 0x7f12b55a8b9d in g_signal_emit_valist ../../../gobject/gsignal.c:3498
#9 0x7f12b55a90d2 in g_signal_emit ../../../gobject/gsignal.c:3554
#10 0x7f12b558e283 in g_object_dispatch_properties_changed ../../../gobject/gobject.c:1206
#11 0x7f12b55906f1 in g_object_notify_by_spec_internal ../../../gobject/gobject.c:1299
#12 0x7f12b55906f1 in g_object_notify ../../../gobject/gobject.c:1347
#13 0x7f12b5dbf54f in _gdk_display_manager_add_display ../../../../gdk/gdkdisplaymanager.c:479
#14 0x7f12b5589a55 in _g_closure_invoke_va ../../../gobject/gclosure.c:873
#15 0x7f12b55a8b27 in g_signal_emit_valist ../../../gobject/gsignal.c:3407
#16 0x7f12b55a9b7b in g_signal_emit_by_name ../../../gobject/gsignal.c:3594
#17 0x7f12b5ded21a in _gdk_x11_display_open ../../../../../gdk/x11/gdkdisplay-x11.c:1803
#18 0x7f12b5dbf377 in gdk_display_manager_open_display ../../../../gdk/gdkdisplaymanager.c:462
#19 0x7f12b5822f6a in gtk_init_check ../../../../gtk/gtkmain.c:1109
#20 0x7f12b5822f6a in gtk_init_check ../../../../gtk/gtkmain.c:1101
#21 0x7f12b6fd1dad in wxApp::Initialize(int&, wchar_t**)
...
Don't return anything from it, just warn directly -- this is what all
the existing callers did, so it's simpler if the function just does it
itself instead of forcing them to check its return value.
Also reset m_painted after yielding, so that YieldUntilPainted() could
be called again, if necessary.
Running wxWebView tests with ASAN results in "ASan runtime does not come
first in initial library list" warnings and doesn't work currently, so
disable wxWebView in this build for now to have a chance of passing the
tests.
It would be better to actually fix this, of course, but this will have
to wait until later.
We need to explicitly link with the system libraries required in this
case, as static wxwebview library doesn't pull them in (it's also better
to link with them explicitly even when using shared libraries, but in
this case linking at least still worked due to transitive dependencies).
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.
Respect wxTE_PROCESS_TAB and wxTE_PROCESS_ENTER flags even for readonly
text controls. Previously there were ignored for them due to the changes
of 080c709f70 (fix for handling TAB presses in readonly text controls,
2002-09-07), but there doesn't seem to be any good reason to do this, so
revert the changes of that commit by removing IsEditable() check from
our WM_GETDLGCODE handler.
We also need to avoid inserting TABs into readonly controls ourselves in
the default wxEVT_CHAR handler, so add a check for IsEditable() there to
compensate for the fact that these events are now received even for the
readonly controls.
This commit is best viewed ignoring whitespace-only changes.
Closes#19064.
The order of refcounting operations should be the opposite of what it
was: first check if the path is not watched already and only if it is
not call m_service->Add() to actually watch it. (Previously reference
count was kept track of, but m_service->Add() was always called, i.e.
the calls were repeated and unbalanced with Remove() calls.)
Remove() already has the correct order and only calls
m_service->Remove() when the path's refcount reaches zero.
This fixes a problem which was there since the original code was added
back in 76cfd1bf95 (Make wxFileSystemWatcher watch entries
reference-counted., 2012-10-15).
Closes https://github.com/wxWidgets/wxWidgets/pull/2203
This might break using it with the older versions, but it's not clear
whether we still need to support them, so for now apply the simplest fix
which works with the recent NDK and we'll add configure tests later if
we really need them.
See https://github.com/wxWidgets/wxWidgets/pull/2195
