Using base class methods such as AppendBitmapColumn() resulted in
wxDataViewListCtrl::AppendColumn() being called but this function always
assumed the column was of "string" variant type -- which was, of course, false
for bitmap columns and so resulted in heap corruption (thanks to the
wonderfully type unsafe code using wxVariant) and a crash.
Get the correct type to use from the column itself now to fix this.
Closes#16008.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75946 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling Found() without providing the second "value" argument started
generating an assert since introduction of the negated options as it reused
FoundSwitch() which can only be used for switches, i.e. options without
values.
Fix this to revert a regression since 2.8 and also add unit tests for the
different Found() overloads.
Closes#15986, #16001.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75939 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just extract the code for finding options from their names
into a separate function instead of repeating it 4 (and 5, after the next
commit changes) times.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75938 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We can receive WM_NOTIFY for other than CDN_XXX messages if we have a native
control as our immediate child (which can happen with "extra" controls) and
the LPARAM is not a pointer to OFNOTIFY at all in this case, so don't try to
use it as such.
This fixes a crash when adding a "bare" extra control, see #16003.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75937 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMSW automatically extended wxTextCtrl length limit beyond the tiny standard
32KB when it was exceeded, but part of the text being appended into the
control was lost when doing it.
Fix this by retrying insertion after extending the limit.
Closes#15980.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75936 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Do it only once now that it's used in 3 different places (it recently started
to be used in src/msw/anybutton.cpp as well) instead of defining it thrice.
This also fixes MinGW build.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75929 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is an incompatible change compared to 2.8 which can make the existing
code crash and it also goes against the usual rule that the windows are never
owned by sizers, only other windows.
Closes#15698.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75922 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Starting to watch a path, stopping to watch it, starting to watch it again and
stopping again resulted in a crash in wxMSW wxFileSystemWatcher implementation
because the watcher object wasn't kept artificially kept alive when it was
stopped for the second time. This happened because our way of keeping it alive
was to store it in a hash map indexed by path, but if a watcher for the same
path (added there when this path was first unwatched) was already present in
the map, the watcher wasn't added to it and not kept alive.
Fix this by using a vector instead of a map. We obviously sacrifice quick
access to it by path but at least this doesn't crash any more. And we could
actually still use a map, just indexed by the (unique) pointer to the object
stored inside wxSharedPtr itself, and not its path. But a vector might be a
more efficient data structure in practice, if we keep it from becoming too big
as we should try to do by triggering artificial port completions when a watch
is removed.
At any rate, at least the crash is fixed for now.
Closes#15995.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75915 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Attempts to wait for thread termination after wxTheApp was destroyed resulted
in an error in wxMSW since 2.9.something whereas it used to work in 2.8 and
also generally makes sense to be allowed. So do make this work again by
falling back to the simple non-interruptible wait for thread if we don't have
the application object any more.
Closes#13391.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75914 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Due to a typo when copy-and-pasting code wrong control was being updated.
It would be better to have a function updating the given control from the
given flag, of course, but for now just fix the bug.
Closes#15990.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75913 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make sure that OnInit() is called before MacReopenApp(). This is
normally the case, but it is possible for it to be called as the first
thing. This can happen when OS X restores running apps when starting a
new user session. Apps that were hidden (dock only) when the previous
session terminated are only restored in a limited, resources-saving way
- the event loop is running, but didn't call anything in the app
delegate yet. When the user clicks the icon,
applicationShouldHandleReopen: is called, but we didn't call OnInit()
yet. In this case, we shouldn't call MacReopenApp(), but should proceed
with normal initialization.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75886 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The user typically can't do anything about this error anyhow, so don't show it
by default. Still do show it when running in the verbose mode as this might
add diagnosing the problem when something goes unexpectedly wrong.
Closes#15944.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75838 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is not necessary as there is nothing that can be done about this error
anyhow and the function still "works" even if it occurs (it doesn't wake up
anything but it is not necessary to do it if the message queue is already
full) and, worse, results in a crash due to stack overflow.
Closes#15951.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75834 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't delay the TLW destruction if it has a parent and its parent is already
being deleted: we can't delay the inevitable in this case and only succeed in
making the program crash if we try.
Closes#15743.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75833 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The changes in this revision meant to prevent the closure of transient dialogs
from quitting the application (see #15880) prevented any application using AUI,
including the aui sample, from exiting as the AUI utility frames deleted
during the main frame destruction were returning false from their
IsLastBeforeExit() now.
Fix this by relaxing the check and ignoring the parent if it is already being
deleted anyhow -- in this case there is no danger of closing it accidentally.
Closes#15894.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75832 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The test failed with 33% probability because it didn't account for
trailing non-newline character. Fixed and also changed the test to
repeat itself a hundred times, to increase the probability of catching
problems like this.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75824 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove the complicated parsing state machine that contained bugs with
unexpected inputs and was very hard to modify correctly. Replace it
with much simpler code that looks ahead, instead of deducing line
endings from past characters.
The new code never looses lines with data and calls AddLine() on the
first newline character it encounters, peeking ahead to determine the
line ending type.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75803 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
