This allows to avoid initializing the variables to 0 in all the
overloaded ctors: wxSize default ctor already does it.
It's also more convenient to use GetScaledSize() rather than assigning
m_width and m_height separately, even if the rest of the code is broadly
unchanged.
We can reuse another ctor taking wxWindow* instead. Although this does
require an ugly cast, it's more explicit than just passing 0 which
could, in principle, match both the ctor taking wxWindow* and another
one taking double, and so is still preferable.
This is similar to the previous commit and is done for the same reasons:
screen DC needs to use the same DPI as the screen itself, instead of the
default Cairo 72 DPI.
For wxDC associated with a window, such as wx{Window,Client,Paint}DC,
this method should return the window PPI, not the hard coded 72 DPI of
Cairo graphics context.
This still doesn't work correctly when using multiple monitors with
different DPI settings, but is still a (modest) improvement.
Recent sorting-related changes resulted in calling FindNode(), which
can only be used with the non-"virtual list" models, unconditionally,
after the items values was changed by user, resulting in a crash.
Add the missing IsVirtualList() check and also add a comment explicitly
stating that all code involving wxDataViewTreeNode can only be used
after checking that IsVirtualList() returns false.
Closes#18057.
The comparator used with std::sort() must return true only if the first
item is strictly less than the second one, this is a requirement of the
sorting algorithm and not respecting it results in wrong final order.
See https://github.com/wxWidgets/wxWidgets/pull/642
This reverts commit 1dd102d741 as it
introduced a crash in the same method when using generic wxDataViewCtrl
implementation, e.g. under MSW, and is not necessary to avoid the crash
with wxGTK3 any longer after the few previous commits.
There is an impedance mismatch between wxDataViewCtrl API, which allows
deleting all items of the model at once, and GtkTreeView, which only
allows deleting them one by one, so bad things happen when we start
deleting the items from the GTK+ model after already having deleted them
from the wxDataViewModel, due to dereferencing the already freed
pointers.
Work around this by explicitly marking the model as being "temporarily
unsafe to use" by setting the stamp, uniquely identifying it, to 0 (and
ensuring that it's never 0 during the normal operation), and checking
for it in all functions that are called by GTK+ from inside
gtk_tree_model_row_deleted() that we call from Cleared().
The fix is not ideal, as the list of these functions was determined
empirically and could change in the future GTK+ versions, and also ugly,
but there doesn't seem to be any other way around this and at least now
Valgrind doesn't report invalid memory reads after calling
wxTreeListCtrl::DeleteAllItems() as it did before.
Check that we have an associated text entry before clearing it.
Fixes a crash introduced by 72fe57ec18
without reverting it as it still seems reasonable to use Clear() here.
Closes#18013.
Remove various definitions and symbol declarations from
numerous files using msw/uxtheme.h to a single file.
When possible vssym32.h is included from the Windows SDK.
For older SDKs tmschema.h is included and missing symbols
are defined in msw/uxtheme.h.
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
When having a certain creation sequence, these popup windows were not focused correctly, see https://github.com/wxWidgets/wxWidgets/pull/672 , commit d2265136e359df4d14054860a68bbc7f4910279d , revert this change if problems arise to see whether this is a recursion
Almost totally rewrite the resize-after-toggle code in this control so
that it actually makes sense and works, especially in the situations
when the contents of wxCollapsiblePane changes, for example when it
contains another wxCollapsiblePane inside it which can be collapsed or
expanded. Previously, this didn't work at all in wxGTK and the inner
pane always remained at its minimal, collapsed size. Now it does, after
doing the following:
First, replace the completely useless DoGetBestSize() which just did the
same thing as its base class implementation with the code actually
determining the best size of the window that was previously hidden
inside gtk_collapsiblepane_expanded_callback() for some reason. Note
that the comment about "not caching the best size" in the old code was
very out of date and was probably left over from the days when
GetBestSize() itself was virtual, as caching is not done in
DoGetBestSize() anyhow, but in GetBestSize() itself.
So, second, do fix the best size invalidation by doing it explicitly
whenever the pane is toggled. And, relatedly, do not set the min size of
anything because this overrides the layout computations and is never
reset/invalidated, unlike the best size, even if the best size of the
pane changes, e.g. because of a change to its contents.
Finally, remove many thoroughly outdated comments, e.g. the one speaking
about OnStateChange() which doesn't exist at all in this implementation.
A pane using wxCP_NO_TLW_RESIZE would generate wxCollapsiblePaneEvent
even when toggled from a program because the GTK+ callback didn't take
m_bIgnoreNextChange flag into account in this case.
Fix this and also avoid duplicating the code for sending the event.
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
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.
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.
