The underlying Windows TaskDialog supports adding an additional footer
to the message dialog. This makes the native functionality available
and implements it in the generic version.
See https://github.com/wxWidgets/wxWidgets/pull/573
Testing for xlocale.h was due to a misunderstanding, this header wasn't
supposed to define locale_t which is defined by locale.h itself and was
just some internal glibc header which was removed in its 2.26 release,
see
https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27
Stop checking for it in configure and also don't always define
wxUSE_XLOCALE but only do it if the configure test succeeded.
Trying to be smart by setting m_isEnabled to false in
wxStaticBox::Enable() without actually disabling the box itself (because
it can't be done if its label window is to remain enabled) didn't really
work. For example, it was impossible to TAB to a checkbox label of the
box when it was disabled, because keyboard navigation (correctly)
doesn't recurse into disabled windows and there could be similar
problems with any other code iterating over windows and skipping over
the disabled ones.
So, finally, simplify things and keep m_isEnabled in sync with the real
box state, even if this, counter-intuitively, means that IsEnabled() on
the box returns true after calling Enable(false) on it.
This also reverts 4ee35cf5ee569b6ee6c7d0d5702484d4d2a20f96 ("Don't
disable wxStaticBox children at wx level when disabling it") as we can't
avoid really disabling the children any more now that their parent is
not disabled: without this, their IsEnabled() would return true, i.e.
they wouldn't be disabled at all, from the program point of view. This
is unfortunate for the reasons that originally motivated that commit,
i.e. if some wxStaticBox child is disabled, disabling and re-enabling
the box will now re-enable this child, even if it shouldn't, but seems
impossible to avoid. The only possible alternative is to modify
IsEnabled() to add some wxStaticBox-specific hook to it, e.g. instead of
calling GetParent()->IsEnabled() there, we could call some now
AreChildrenEnable() method, which would delegate to IsEnabled() by
default but overridden in wxStaticBox. However this seems complicated,
and will add an extra virtual function call to all (frequently
happening) IsEnabled() calls.
Remove wxBookCtrlBase::AcceptsFocus() returning false as it didn't make
any sense: even though wxBookCtrlBase doesn't, indeed, accept focus on
itself, it does accept it for its children and returning false prevented
the focus from ever getting inside it.
This fixes, for example, keyboard navigation in a window containing
wxSimplebook and TAB can now be used to move to the controls inside it
from the outside.
Also remove the now unnecessary AcceptsFocus() override which was just
undoing the damage of the base class method and is not needed any more.
Reset m_pMainWnd in wxMFCApp::ExitInstance() to avoid crash when
deleting it again in OnMainWindowDestroyed() that could happen if
ExitInstance() was called not because the main window was closed (normal
case) but because wxApp::ExitMainLoop() was called, as it happens when
an unhandled exception is thrown.
If wxApp::OnExceptionInMainLoop() returns false, we're supposed to exit
the application by stopping its main event loop, not the loop that is
currently running, so do the former instead of the latter.
Also call wxAbort() if we can't exit the application in any other way,
this is not ideal, but still better than not doing anything and, for
example, keeping showing the same "Unexpected error occurred" message
box to the user over and over again if the exception comes from an event
handler being called repeatedly, such as wxEVT_PAINT or wxEVT_IDLE.
GTK+ 3 (but not the generic version nor even GTK+ 2, apparently) sends
"selection changed" event from gtk_tree_model_row_deleted() when
deleting the currently selected row, which resulted in sending of
wxEVT_TREELIST_SELECTION_CHANGED events with invalid wxTreeListItem,
containing a dangling pointer, and a crash in the treelist sample when
trying to dump it.
Avoid this by clearing the model (and hence generating these events)
first and deleting the items only afterwards.
Also add a trivial unit test for wxTreeListCtrl::DeleteAllItems(), which
doesn't even allow to reproduce this bug, but is still probably better
to have than not to.
Closes#18045.
Checking that a pointer is non-null before dereferencing it is perfectly
useless: the code will crash anyhow, so assert doesn't help with
debugging it in debug builds nor with preventing the crash in release.
SetHasChildren(true) must be called before checking GetChildNodes() if
the parent hadn't had any items in the initial model.
Also remove the assert checking that the node is open in
BuildTreeHelper() as we may need to build even a closed tree branch.
Calling ItemAdded() on a parent item that had never been opened yet
"lost" all its children that initially existed in the model, as the
corresponding subtree wasn't built any more in Expand() when this item
was finally opened because the list of item children wasn't empty any
more after ItemAdded() added the new child to it.
Fix this by simply not doing anything in ItemAdded() in this situation,
there is no need to update a closed tree branch immediately anyhow.
There doesn't seem to be any good reason for this, as it's perfectly
possible to use ellipsize the text if it's too long to fit even when the
control is resized to its maximal extent, but still allow the control to
resize in the first place.
See https://groups.google.com/d/msg/wx-dev/58xFP4FIxXc/d5lj6901CQAJ
Refactor wxStaticText code to use AutoResizeIfNecessary() for all the
updates done after the label extent changes (whether it's due to the
change of the label itself or the font used for rendering it).
There should be no changes in behaviour after this commit except for a
small bug fix in wxGenericStaticText when setting label with markup:
this didn't invalidate the best size before, but does now.
Recent optimizations avoiding resort on item change (see
https://github.com/wxWidgets/wxWidgets/pull/642) have also optimized
away refreshing the modified item, which was done implicitly, as a side
effect of resorting, before, so the changes were not reflected on
display immediately any longer.
Fix this by simply refreshing the item explicitly and also add a way to
test for the correct behaviour in the sample.
No real changes, just add the new DoItemChanged() used from both
ItemChanged() and ValueChanged() notifications to avoid repeating the
same code in both functions.
The wrong order of changing parent and freezing/thawing could result in
hanging the application when reparenting frozen windows, e.g. when
switching order of pages in a notebook.
Closes#16722.
Merge ctors from (width, height) and (width, height, scale) into a
single one because the former really should be just a special case of
the latter for scale == 1 but, surprisingly and confusingly it wasn't,
because the latter also multiplied the size by scale, meaning that width
and height parameters had different meanings.
This resulted in at least 3 bugs when using scale factors different from
1: first, copying bitmaps wasn't done correctly because as
wxBitmapRefData copy ctor incorrectly scaled its size by scale again.
And second, creating bitmap from wxImage whose size wasn't divisible by
scale not just didn't work correctly but crashed when accessing memory
outside of the image because (unnecessarily) dividing and multiplying
the image size by scale wasn't idempotent. Finally, even for the images
of even size (assuming scale factor of 2), bitmaps created from them
used incorrect width and height, corresponding to the half of the image
dimensions, instead of the same ones, as they're supposed to be (the
scaled dimensions are supposed to be returned by GetScale{Width,Height}
methods).
Closes#17505.
There is no need to handle this style specially here, it's supposed to
be handled at wxWindow level and is, indeed, at least in all the major
ports.
So revert 2119b213e3 (see #13616) and the
workaround for it applied later for macOS (see #14856). And this also
removes the need for handling wx[HV]SCROLL in wxScrolled (see #17846).
Closes#14856, #17846.
Several compilation fixes due to the fact that sizeof(long)==8 under
Cygwin in 64 bits.
This allows the library to compile, but there are still run-time
problems, notably the unit tests throw an unknown exception currently.
Even though we don't need to perform the checks for the availability of
<unordered_map> or <type_traits> headers when using C++11 because we can
safely assume they're indeed available, we still need to define the
corresponding symbols, as if the checks were performed, so that the code
inside and outside the library could test them in any case, whether
we're using C++11 or not.
When using configure, use the same family of hash sets/maps when
building wxWidgets and the applications using it as doing otherwise
results in ABI incompatibility.
Avoid showing message boxes even if we don't have the associated console
as this prevents the test from completing on its own if an unknown
exception happens.
This is another fix for 64 bit Cygwin build: LONG is defined as a 32 bit
type in it, but not long, which is 64 bits, so use the former instead of
the latter.
Due to the same problem with sizeof(long) mismatch as in the previous
commit, we can't use struct timeval, with its long fields, in 64 bit
Cygwin builds, and need to use __ms_timeval instead.
Add wxTimeVal_t type to hide this difference and update all code
compiled under MSW (there is no need to uglify Unix-only code using
timeval, as in wxSelectDispatcher, for example) to use it instead of
timeval.
Use __ms_u_long instead of just u_long with Cygwin to avoid mismatch
between (64 bit) Cygwin long and (still 32 bit, even in 64 bit build)
Windows API long.
Use __LONG32, which is always 32 bits when using Cygwin, unlike long,
which is 64 bits there in 64 bit builds, and so can't be used as an
argument to InterlockedExchange().
Closes#16746.
In some specific scenario, described in the newly added comment in
wxStaticBoxBase::Enable(), the box and its label could remain disabled
after its parent was disabled and re-enabled.
Fix this by continuing to use the derived class version for disabling
the box children, but not when enabling them, as the base class version
already does the right thing in this case.
Calling Enable() on all children from wxStaticBox::Enable() was wrong,
the actual status of the child, returned by wxWindow::IsThisEnabled(),
is not supposed to change just because its parent was disabled.
Call NotifyWindowOnEnableChange() to avoid this, while still disabling
the children visually.
Simplify the code by replacing 2 conditionally-compiled DoEnable() calls
with a single unconditional one.
This doesn't change the behaviour of Enable(), as it always called
DoEnable() on the window itself and only did it for its children when
wxHAS_NATIVE_ENABLED_MANAGEMENT was not defined before and continues to
do the same thing now, but it should fix a small bug in Reparent() as it
didn't update the actual status of the window if it changed as the
result of reparenting before, even though it was supposed to.
There doesn't seem to be any need to have this symbol in the header,
when it's only used in NotifyWindowOnEnableChange() in wincmn.cpp.
No real changes.
