LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
GregFreeman

Remove Common Error Functionality From Set/Unset Busy Cursor

Status: New

I am always putting flat sequence structures around "set" and "unset" busy cursors because if I wire error clusters into them to enforce data flow and an error is passed in, they don't execute. Nothing like having an error occur then your cursor stuck as busy. I suggest having these two subVIs execute even if an error is passed in (just like reference closing/releasing functions do). This way the error cluster can be used to enforce data flow and we can all avoid unnecessary flat sequences. The only issue I see with changing this is if previous code has been written taking the current functionality into account and expects a cursor to stay busy when an error happens and unset busy is managed in the error handling state, or something of the like.

10 Comments
dthor
Active Participant

Why not just put Clear Errors.vi in front of it?

X.
Trusted Enthusiast
Trusted Enthusiast

I learned something today: I usually never connect the error input on a close ref/file, etc, for fear it would not if there had been an error before (that doesn.t break tthe flow since a reference needs to be passed to the function anyway). I never bothered to read the help!

But basically the answer to your suggestion seems to be in it: if there is an incoming error, don't you expect the long code in between the set and unset busy cursor to NOT execute? If this is the case, then you don't want the cursor to "flash" for no good reason.

If you want to execute even if there is an incoming error, then I would say that this is a very specific case and I would second dthor.

elset191
Active Participant

Tangentially related: Visual indication that VI will run even on error

--
Tim Elsey
Certified LabVIEW Architect
GregFreeman
Trusted Enthusiast

dthor: Clear errors is generally not an option because we often need to handle the error. I suppose we can split the wire and clear the split so the error is still passed on.

X: What if the code between the busy and unset busy causes the error? For example, an FTP connection fails, or the network goes down in the middle of a big transfer. This would not result in a "flash" of the cursor, and my cursor is now stuck busy. Same could be said for reading or processing big files.

X.
Trusted Enthusiast
Trusted Enthusiast

Good point. I stopped one step too early. But there I'd say split your error wire and clear it before you pass it on to the Unset Cursor.

 

I am a bit uneasy with the "custom" behavior exhibited by the Close Ref functions (and would be for these VIs), because it goes against the assumption I had made so far that any VI asking for an error input was actually taking it into account (well, with the exception of the OpenG Tick counts which I use all the time BECAUSE they just pass on the error while ignoring it...). Basically, upon error, do nothing or return some default results.

As indicated by the thread you refer to, this is in fact an open question.

This guy just posted a suggestion following up on yours, but I don't think I want to go this way myself.

Altenbach had this suggestion of a "RDV at the bar" which would obviate the need of a sequence structure (again, not sure I am in favor of this either).

I think a generic solution to force sequential execution of VIs/functions without recourse to a massive sequence structure is certainly needed. I would avoid to "patch" individual functions...

tst
Knight of NI Knight of NI
Knight of NI

I agree with the thinking behind this idea, at least for the unset busy VI. The same should probably apply to a Defer Panel Updates property with a value of false.


___________________
Try to take over the world!
Wart
Member

I can't think of a single case where I want my cursor to stay busy (and the default is ignore clicks!) if the code I'm executing between set and unset busy generates an error.  I've always used the error wire for data flow: set busy, execute code that isn't meant to be interrupted and may take a while to execute, unset busy.  The unsetting has nothing to do with the outcome of what happens in between.

GregFreeman
Trusted Enthusiast

tst: I believe your'e right, and there are probably other functions that should still execute despite an error being passed in. But I don't know how this could potentially upset current code that expects and handles an incoming error in these situations. I think this goes back to the "best practices" of including an error case structure in every subVI, which should maybe be ammended. Discussed some over at LAVA in this thread

AristosQueue (NI)
NI Employee (retired)

There's actually a tricky part here... you may not want to execute the Set Busy once you're in an error state because you're not going to do whatever it is that you're calling Busy for. You only want to call Unset Busy if you did Set Busy. If you call them in quick succession, all you do is create flickering for your end user.


I like the sentiment of the idea. Can we figure out some way to resolve this? What does "Acquire Semaphore" and "Release Semaphore" do? They have the same issue.

AristosQueue (NI)
NI Employee (retired)

For the record, I've been suggesting around the office that pairs of functions where "only execute the second if the first executes" applies should have some way of attaching to the Inplace Element Structure. I haven't posted the idea to the Idea Exchange. My question from above for "can we find some way to resolve this?" should be read as "just by changing these VIs in existing G code, can we make the situation better?" avoiding the question of "what big idea can we create to solve the real root problem?"