Return to previous case

[mwebster]

I was poking through some old code on Friday that had a case structure of 100+ cases and it became really annoying to be working in a case, flip to another one to check what it was doing, then going back to the original case.  I would love to have a return to previous case function (How about ctrl+shift mousewheel to flip between the two most recent cases?)

 

I looked in the VI Scripting nodes, but it looks like CaseSel only holds the current visible case and doesn't track previous ones.  I gave about 90 seconds of brainpower to thinking about writing some sort of tracker that runs in parallel, but I'm not at all experienced with VI Scripting and it made my brain hurt to try to track each and every case in every open VI.  If anyone knows a way to do this easily, let me know.  If not, maybe I'll petition the Labview Gods to add a previousVisibleCase property to CaseSel objects.  With something like that, I think it would be pretty simple to write an RCF plugin or a ctrl+space shortcut.

 

Mike

[ShaunR]

I was poking through some old code on Friday that had a case structure of 100+ cases and it became really annoying to be working in a case, flip to another one to check what it was doing, then going back to the original case.  I would love to have a return to previous case function (How about ctrl+shift mousewheel to flip between the two most recent cases?)

 

I looked in the VI Scripting nodes, but it looks like CaseSel only holds the current visible case and doesn't track previous ones.  I gave about 90 seconds of brainpower to thinking about writing some sort of tracker that runs in parallel, but I'm not at all experienced with VI Scripting and it made my brain hurt to try to track each and every case in every open VI.  If anyone knows a way to do this easily, let me know.  If not, maybe I'll petition the Labview Gods to add a previousVisibleCase property to CaseSel objects.  With something like that, I think it would be pretty simple to write an RCF plugin or a ctrl+space shortcut.

 

Mike

Not exactly what you are asking for but it may be suitable even if not perfect (case select-it uses the JKI plugin framework). Alternatively, it would be a very good starting point for your own framework plugin.

[jcarmody]

Shaun's link doesn't work.  Here's the Quick Drop plugin he referred to that does what you want, sorta...  The navigation feature doesn't completely work as I lost interest in developing the plugin before getting all of the wrinkles out.  It does a WHOLE LOT MORE, though, that you may like.  I wrote it because I had Case structures with too many states.

 

Those left/right arrow buttons do what you're looking for, albeit imperfectly.  They'll kinda-sorta let you navigate through your history (that you've made using the plugin).  It works well enough that I can/do use it, but it makes unintuitive mistakes.  The rest of the tool lets you see all of the states, activate one, rename/move/delete/create...  It's a life-saver when working with the type of software you described.

 

It requires the JKI State Machine, but not their Right-Click Framework (that stopped working years ago so I converted it to Quick Drop).

 

It only works in LabVIEW 2012.  The link to the NI Quick Drop Community page is the latest-and-cough-greatest version.

 

[GregFreeman]

Not necessarily an answer to your question, but if I had that many cases I would start to think about my architecture. That seems like you are handling too much in a single loop. You may want to consider more dedicated processes. The only case I can really think of that may have this many cases is message mediator, that handles/routes all messages in the system.

[jcarmody]

Not necessarily an answer to your question, but if I had that many cases I would start to think about my architecture. [...]

That was my concern four years ago yesterday...

[mwebster]

Thanks Jim,

 

This looks like a good solution for those individual situations where you have a mega-case structure.  However, I am having trouble getting the code to run reliably.  I'm getting Error 1026 at a property node in caseselect.vi Possible reason: VI reference is invalid.

 

It seems like if I leave the errored out instance open AND I open up QD_CaseSelect.vi it will work.  When I close one or the other it sometimes works.

 

...

 

Alright, I dug down into the code and saw you had a 1ms pause in Dynamic Launch CaseSelect.vi between Run VI and FP.Open.  I bumped that up to 10ms and it seems to be working now.  Go figure. ...

 

Hey, it even detected my dummy cases and let's me tree-collapse them.  Very nice.

 

 

As to the architecture, this is one of those fun projects that has grown incrementally over the years.  The initial version was quite manageable, but we've been through a dozen add-on functions since then and it's gotten ever more unwieldy. 

[jcarmody]

Alright, I dug down into the code and saw you had a 1ms pause in Dynamic Launch CaseSelect.vi between Run VI and FP.Open.  I bumped that up to 10ms and it seems to be working now.  Go figure. ...

Oh, noes!!!  I must have had this, or a simliar, problem years ago that this Wait fixed.  I couldn't remember why I added it, which explains the comment I put in later...

 

Someone else had this problem, too, but I can't find the discussion we had.  You may have fixed that one, thanks.

[Ton Plomp]

Why don't you let the VI itself open it's FP?

And if you have a large case structure, it's wise to add a piece of code after CS that inserts the case selecter info into the error data.

 

TOn

[jcarmody]

Why don't you let the VI itself open it's FP?

And if you have a large case structure, it's wise to add a piece of code after CS that inserts the case selecter info into the error data.

 

TOn

I understand your first comment, and it works as long as I keep the Wait.  Please explain the second comment.

[Yair]

I gave about 90 seconds of brainpower to thinking about writing some sort of tracker that runs in parallel, but I'm not at all experienced with VI Scripting and it made my brain hurt to try to track each and every case in every open VI.

 

Ignoring what the others have said, you don't actually need to track multiple VIs. The secret is the VI Activation event, which tells you which VI you're now interacting with. You then only need to monitor the case structures in that VI (by polling, since I don't know of any events you can currently get for editing actions). The traverse for refs VI should be your friend and you might be able to use the private UID property to track the specific structures.

 

Here's a quick mod of the template I normally use for quick scripting actions on other VIs (which is itself just a pretty quick mod of Norm's code), where I added the relevant pieces (although I only added it in the action event, whereas you would want it in the timeout, and I didn't check it at all, so the class name might be wrong, or the UID property might not work, etc., and of course, I didn't add the actual tracking code).

Scripting.vit

[jcarmody]

This is what I use when I want to make something for the Tools menu:

 

[Mellroth]

...I was poking through some old code on Friday that had a case structure of 100+ cases and it became really annoying to be working in a case, flip to another one to check what it was doing, then going back to the original case.  I would love to have a return to previous case function (How about ctrl+shift mousewheel to flip between the two most recent cases?)...

 

Not a solution to flip back and forth, but to compare two cases you can open the same VI in two different projects, and get a side-by-side view of the differences.

 

/J