"App jumping driving me nuts!"

[Ryan_Deardorff]

Is there any chance they have fixed this issue in 8.3?

App jumping driving me nuts! | Ignition Features and Ideas | Inductive...

It just happened to me again where I was clicking my way trying to find a particular view, only to find that it had disappeared from the folder where it was supposed to be. I figured the "app jumping" issue had inadvertently moved it somewhere and figured maybe I could just "Undo" but that's greyed out as an option, even though I soon found that the view had indeed moved...

I imagine this bug is related to the fact that the project browser tree doesn't maintain its expansion state:

Designer Project tree should maintain expansion state | Ignition Features and...

[nminchin]

What version are you in?

[Ryan_Deardorff]

8.1.47

[andrew.budaiev]

It would be nice to have the ability to expand and collapse the tree elements. I use "Refresh Providers" frequently to collapse tag browser.

[paul-griffith]

@Ryan_Deardorff

Is there any chance they have fixed this issue in 8.3?

No, not in 8.3.0 at least.

I've tried I don't know how many times over the years to fix this issue, and have never succeeded. The only assurances I can offer are that it also drives us crazy internally and we're not giving up on it.

We have some short(ish) term plans to, even without figuring out what's going wrong here, improve the project browser - expand/collapse all, a "bullseye" to jump the selection to whatever workspace element you're actually looking at, etc. That will hopefully happen in some early 8.3.x release.

[Nol]

A similar issue gets me every time going to named queries and really needs to be fixed someday. You have to click once on the query, then the whole tree moves because it hides the other windows (tag browser in my case), then move the mouse back down to the query and then can double click to open it. If you don't do that and try to double click the first time you end up on a random perspective screen from wherever the tree jumps to.

8.1.47

[nminchin]

@paul-griffith

a "bullseye" to jump the selection to whatever workspace element you're actually looking at

YES that would be gold. It would be nice too for the tag browser to be able to paste a tagpath and have it expand the structure to it

[paul-griffith]

Oh, that's a fun idea. You should make an ideas post for that, I can definitely see how that'd be useful.

[nminchin]

Done! I added some use-cases as well which identify the need

[FEATURE] Add ability to locate a tag path in the tag browser

It would be nice to be able to paste a tagpath into a function attached to the tag browser and have it expand the structure to that tag path. In the same vein, it would be good for the Tag Editor (and the Tag Report Tool) to have a function to be able to "locate" the tag you're editing in the tag browser. The use-case here would be when opening the tag editor from the Tag Report Tool results for instance, where opening it from here doesn't also locate the tag in the tag browser. Idea for votin…

[Ryan_Deardorff]

When a different tab in the main editor pane get selected, it jumps the tree selection to that view, which is what it should do, IF you actually clicked on the tab. I think the problem may be that when I have one view open, and I scroll up to click on a particular element within a different view, it causes that view's tab to become the selected one. I'm guessing that is then triggering a focusing of that view in the tree, which isn't necessary in this case, and is actually moving the selection to the root view node, causing the jumping behavior that is so annoying.

That could explain what I'm seeing with the views anyway, though not necessarily the Reports case shown in my earlier screenshot, where the selected item's grandparent node collapses...