5.3 (5.3.1) RTM 5.4 (5.4.0) RTM

Hi!

When I click the checkbox to select an element in the Derived Element Sub-Element Selection treelist then the node itself gets focussed, which is fine*. But when I click to deselect (uncheck) an element then the top first node gets focussed, this is not so nice when working several levels deep to keep switching back and forth the tree all the time. Sure, I can deselect by selecting multiple elements, but sometimes I have to select a child first and then deselect some elements, then it doesn't work this way.

• with more elements in the tree than can fit on the screen, which is most of the time, then when checking the element the node gets selected but visually becomes the top node in the tree. It would be nicer if it just gets selected, no other 'behaviour'.

When editing an element name in the Shape editor, this behaviour is also noticed.

It might be usefull to have an option in preferences that keeps current behaviour and one that doesn't (re)focus on (un)checking to keep current customers happy. (although I might think the current UX does not make any one happy, but that's my personal opinion)

I can understand unselecting on the left in the Selection tree deletes the element in the Shape Editor on the right. Then on the right you must have a new focussed element , this element then synchronizes back to the left. Well you might set the focussed element on the next of previous element, the parent or the root (as now). You might have these optional behaviours.

When we are with it, when selecting an 'Embedded element' or 'Field, set of elements' (both left or right) no refocussing happens, this might be expected/enabled?

kind regards

I see what you mean. It's sometimes unavoidable: we set the 'make visible' flag on the node for the tree control so it indeed makes sure the node is visible, but does this sometimes by placing the node at the top instead of in the middle.

When unchecking checkboxes the focus should indeed stay on the nodes you're unchecking (they're not removed or anything, so they should simply keep the focus). Events happen back/forth and the tree is rebuild and this likely causes the issue, but we have to check.

We'll see what we can do with the user experience as it can indeed be better. No need for a setting, as I agree I don't think anyone wants this behavior over what you suggest.

great! thanks for your understanding.

Your first point was fixed before 5.0 beta, but only for checking a node. For unchecking a node, you still get the old behavior which should never happened. Looking into it now.

(edit) fixed in next hotfix build. Looking into your other points now

(edit) the selection of set nodes (navigators or field, set of elements) indeed doesn't select its counterpart on the other side. This is by design as the fields drive the shape, so if a field gets unchecked / checked the unchecked/checked behavior of the parent follows from that, so keeping the selection in sync in the left / right pane respectively isn't really needed as most of the time you're going to select fields, not navigators / sets.

So I think that covers your points I'll push a new hotfix build now for both 5.3.6 and 5.4.1

(It's now available)