Version 5.0.4 Build 17-Jun-2016 on Windows 10

After I edit my entities' navigator names by right-clicking and selected "Rename..." and editing in the pop-up, the Project Explorer scrolls all the way back to the top. I have a large project with lots of entities and this makes it frustrating.

Reproduced when the tree of the Project Explorer is large. We will look into it. In the meantime you can help yourself using the quick search box of the project explorer.

The tree is rebuild looking like it's previous state, but when a node is renamed, it can't find it back and will opt for the first node. The reason is that nodes are identified based on their path to the root and their own value, as multiple nodes can represent the same element, the element itself isn't a proper ID. A guid isn't either as the tree is build from scratch after some changes (not all) so it's not going to help.

We'll see if we can find something to set the focus back on the node or its parent perhaps.

It's not due to a repaint issue, the tree isn't rebuild with this action.

The problem is due to the fact the tree scrolls to the top if the selected node (the 'focused node') is removed. This is also the case when a field is selected and it's removed from the entity in the entity editor. The tree won't scroll if another node is selected and the field is removed in the entity editor.

We're looking into it.

FYI, I've noticed that the item that is edited retains its selection state. This help me find it again when I have to scroll down.

I think we've fixed it, but it's tricky: it's hard to determine when the focused node is removed, as the tree itself doesn't have an event for that so it's not easy to intercept it (and as everything is event driven, it's not doable to add code everywhere to see whether things have changed).

What we've done is cache the focused node before a batch operation starts on the tree and check after the batchjob has been performed whether there's still a focused node. If not, we check if the cached focused node is still in the tree, if not, we use its also cached parent, check that and if either is in the tree, we pick that one instead, otherwise we give up.

This results in the tree keep its scroll position when renaming / removing elements, the focused node is then just moved to its parent.

Could you please try v5.0.5 hotfix build of today, available under 'my account -> 5.0 downloads' and see whether this works for you and if there are glitches we haven't anticipated?

Emmanuel wrote:

FYI, I've noticed that the item that is edited retains its selection state. This help me find it again when I have to scroll down.

True, but that's not usable for solving it, I think: if you remove a field you have the same behavior and that's of course not what you want.

Please let me know if the fix works or if it still is too rigid. I think we might be able to cache a sibling node instead of a parent, but the problem is, if you e.g. remove all the fields of an entity, you want to focus on the parent instead.

Hotfix (v5.0.5) fixes the issue. Thanks.