The TreeListItem.DeleteChildren() method iterates over the list of a
parent item's children (self._children) and calls tree.Delete(child)
on each one (hypertreelist.py line 1365):
for child in list(self._children):
child.DeleteChildren(tree)
if tree:
tree.Delete(child)
The TreeListMainWindow.Delete(item) method however removes the child
from its parent's list directly (hypertreelist.py line 2546):
parent = item.GetParent()
if parent:
parent.GetChildren().remove(item) # remove by value
This ends up modifying the list as we are iterating over it. The end
result is that every other child and its children do not get cleaned up
properly before being deleted. The biggest issue being that any windows
belonging to the children won't be destroyed, and instead orphaned in
the control.
If any two elements of self._value are equal, sorted tries to sort by the next element in the zipped tuples, resulting in
TypeError: '<' not supported between instances of 'Colour' and 'Colour'
Specifying a key to sort only by the first element prevents this.
If a window is created and added to CustomTreeCtrl or HyperTreeList its initial position will be incorrect and if the item it was added to is hidden (child of collapsed item) the window will be shown in an incorrect spot (usually 0,0 i.e. top-left of control).
In CustromTreeCtrl and HyperTreeList when a window is added or deleted
from an item the row height can change causing the entire tree to
change shape. This sets the _dirty flag so the tree gets recalcualted
during the next Idle handler.
In HyperTreeList deleting an item didn't properly remove it from the
_itemWithWindow list.
Hiding items was only partially implemented and very buggy.
This feature does not exist in CustomTreeCtrl but I see no reason why
it couldn't be added in the future. This fix requires the arrow key fixes
in order for arrow keys to work reliably in a tree with hidden items.
Hidden items always report they are disabled and not expanded.
Also updates the demo of HyperTreeList to add hide options to context
menu so the feature can be tested.
Fix item window positions on scroll with arrow keys (Issue #1059).
Affects CustomTreeCtrl and HyperTreeList.
Child window positions don't get updated when using the arrow keys to
move up/down through the tree on most platforms (msw, osx, gtk3).
It seemed to only work in gtk2.8.
Switching from using the SetScrollbars() method to the Scroll() method
repositions child windows more reliably.
In CustomTreeCtrl and HyperTreeList the `CalculatePositions` method
scans the tree and recalculates positions of all items. It is called
whenever the tree topology changes and also in the `OnInternalIdle()`
handler when the `self._dirty` flag is set.
The `CalculateLevel` method must also position child windows properly
to avoid glitches when the tree is drawn. Previously, child window
positions would only be updated when their item's row was painted.
Since the tree is drawn top to bottom the old window position could
occlude painting of previous rows until the position was updated,
leaving blank patches in the tree. This is most visible when the
TR_ROW_LINES style is used.
Also adds a 2-pixel margin to HyperTreeList OnPaint() method.
This is done to match the 2-pixel margin added in the
`CalculatePositions` method:
```y, x_colstart = 2, 0```
CustomTreeCtrl also does the same thing. Avoids needless
repositioning of child windows.
If customtreectrl.py or hypertreelist.py modules are run the latest
wxPython versions will throw Assertion errors if the locale is not set.
wxAssertionError: C++ assertion "strcmp(setlocale(LC_ALL, NULL), "C")
== 0" failed at ..\..\src\common\intl.cpp(1579) in wxLocale::GetInfo():
You probably called setlocale() directly instead of using wxLocale and
now there is a mismatch between C/C++ and Windows locale.
Things are going to break, please only change locale by creating
wxLocale objects to avoid this!
In CustomTreeCtrl and HyperTreeList the `SetPosition` method is used
to adjust window positions. This can't set a Y value of -1 and instead
leaves the window at its last position. Use the `Move` method instead.
Also made sure this positioning is done before a possible call to the
`Show` method which prevents some flicker.
CustromTreeCtrl key handling fixes:
UP key not working if previous item's children were disabled.
DOWN key not working if the next parent was disabled.
END not working when the last item in the tree is disabled.
HOME not working if the top item in the tree was disabled.
Adds handling for PageUp and PageDown keys.
Previously CustomTreeCtrl would let these keys be handled by the
ScrolledWindow subclass which scrolls by a page but doesn't update the
selection. This change moves the selection to the first/last visible
item, or by an entire page if the first/last visible item is already
selected. This mimics native control handling and avoids disabled items.
Adds two methods: GetPrevShown() and GetNextShown().
The GetNextSibling() and GetPrevSibling() methods in CustomTreeCtrl
will throw an exception if the item has been deleted from the tree.
This happens whenever an item is deleted but the selection isn't
updated. The exception will be thrown on the next key press. Can be
observed easily in the HyperTreeList demo.
If a HyperTreeList is created with only the root item present, and not
selected, an exception will be thrown if any key is pressed.
GetFirstVisibleItem() returns None, even though the root item is
present and visible. Only an issue if the TR_MULTIPLE flag is set.
Allow use of numpad +. -. and * keys as well as the Windows menu key in
addition to regular keys.
Fix wrong method call to self.ExpandAll(), now self.ExpandAllChildren().
Note: The code still compares against ord('+') and ord('*') which isn't
valid for wx keycodes and will never evaluate properly.
If the user presses the plus '+' button, on most keyboard this will
result in an ord('=') keycode with the SHIFT modifier set.
Regression caused by PR #886
`on_the_right` is used as positional argument where `separator` is
expected causing a line to be drawn through root item.
This change specifies keyword arguments explicitly.
Since I had to fix a image issue and optimize it. I decided to rerun FileOptimizer 13.30.2393 over all pngs. Small bytes for some that had been optimized before, but this comit covers all pngs that may have been missed in the past. Maybe revisit running them all again in 2 years. Total time to process all pngs: approx 8 hours.
As technology improves this will only get better/faster when downloading, loading in browser, embedded, etc...
