Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Project Explorer Scrolls Back to Top After Editing a Node
 

Pages: 1
Bugs & Issues
Project Explorer Scrolls Back to Top After Editing a Node
Page:1/1 

  Print all messages in this thread  
Poster Message
Emmanuel
User



Location:
Ottawa, Canada
Joined on:
13-Jan-2006 23:14:31
Posted:
167 posts
# Posted on: 25-Jul-2016 23:47:34.  
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.
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8110 posts
# Posted on: 26-Jul-2016 07:49:24.  
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.

David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 26-Jul-2016 10:43:06.  
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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 26-Jul-2016 15:33:17.  
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.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Emmanuel
User



Location:
Ottawa, Canada
Joined on:
13-Jan-2006 23:14:31
Posted:
167 posts
# Posted on: 26-Jul-2016 15:35:39.  
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.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 26-Jul-2016 16:46:45.  
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.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Emmanuel
User



Location:
Ottawa, Canada
Joined on:
13-Jan-2006 23:14:31
Posted:
167 posts
# Posted on: 26-Jul-2016 17:44:52.  
Hotfix (v5.0.5) fixes the issue. Thanks.
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.