Abort all VIs Button in Taskbar (Modal Windows Problem)

[inversion]

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂

[AristosQueue (NI)]

Les__Bartel:

It is not a bug. It is a feature request. Every part of the system is behaving exactly as designed, and none of the the individual designs are flawed in their conception. These features, when taken in aggregate, allow us to write systems that exceed the functionality requirements of any one of these features. This is what happens with successful software -- it is built for one level of functionality, and, if done right, can be stretched to the next level of functionality, and you get lots of feature requests for "if only this were modified, we'd be able to hit this stretch functionality much more easily." But they are not bugs, nor design failures. If you want to differentiate these "revealed gaps" from other kinds of features, the term I would give them is "growing pains".

In this particular case, the origins of LabVIEW focused on each application having a top-level VI. Aborting that would abort all the VIs in the hierarchy. Your top-level VI was *never* a reentrant VI, so even if you hid the panel, it was trivial to use the OS to open the panel so you could hit the Abort button. Then we added features for modal dialogs, which removed the abort button, but abort was still somewhat straightforward either by aborting a subVI or having a VI Server tool that could do it. And it was rare to have your top-level VI be a modal dialog, anyway. But as time has gone by, we have expanded this concept of "modules" in LabVIEW, and we have created free-running components within the larger application, each with their own lifetime separate from that of the original application. And we've made it easier to instantiate reentrant clones, and so on. All of this has given LabVIEW a huge power boost when writing larger scale programs. And now, having written larger scale programs, we all find ourselves wanting new debug tools and environmental controls commensurate with that scale. Not bugs ... just features that haven't been invented yet. And since that list is open-ended, the Idea Exchange helps us (but does not dictate to us) the order in which those features get addressed and what form that addressing should take.

-- AQ

[JonP]

I'm sorry AQ, that is BS. If I run a top-level VI that finishes normally LabVIEW should NOT EVER be in a hung state. I must have wasted hours of time over the years dealing with this problem just because I have a modal VI open in the IDE. The behaviour may be justifiable from an NI blinkered engineering point of view but it is a dreadful experience for the developer so is a BUG.

[wiebe@CARYA]

>I'm sorry AQ, that is BS.

In your opinion. Please be a bit more restrictive in sharing it like this.

>If I run a top-level VI that finishes normally LabVIEW should NOT EVER be in a hung state.

If all top-level VIs are finished normally, LabVIEW is never in a hung state.

>I must have wasted hours of time over the years dealing with this problem just because I have a modal VI open in the IDE.

When I do something wrong, it doesn't work how I want it to either ... That is called a bug.

>The behaviour may be justifiable from an NI blinkered engineering point of view but it is a dreadful experience for the developer so is a BUG.

Something being dreadful does not make it a bug. I find it dreadful to fill in my hour states, but my colleagues don't agree it's a bug. Annoying maybe, inconvenient, sure. Not a bug.

[JonP]

OK, apologies for the "BS" comment, I had just hit the problem and was feeling a little aggrieved! But I did apologize in the same sentence . My comment about finishing normally was misleading I agree, the problem that occurs is that you run a VI and because a modal dialog happens to be open LabVIEW hangs so you can not make anything finish normally. The problem dialog does not even have to be called so I can't see how that isn't a bug.

I agree that it is dreadful to fill up a timesheet but I can understand why it is necessary, however I don't see why it is necessary for LabVIEW to hang just because I happen to have a modal VI open. There is no reason anyone should think "oh, I'd better close all my modal VIs before I run anything because it is obvious that this will hang labVIEW". I have known about this problem for years and I still forget to do it just because it is such unreasonable behaviour.

Anyhow, that's my opinion, but at the very least NI could do something like the OP suggests.

[wiebe@CARYA]

>I agree that it is dreadful to fill up a timesheet but I can understand why it is necessary, however I don't see why it is necessary for LabVIEW to hang just because I happen to have a modal VI open. 

I don't think the problem is that easy. LabVIEW does exactly what it's told to do, as it's a programming language that should do exactly what it's told to do. It's just that in this situation, it's very inconvenient that it does what it's told to do. In other situations, it might actually be expected to have a modal window become a modal window.

Almost like the programmer jokes (this one and this one).

As for a way out, it's not that hard to stop all running VIs, including clones, although there's no way to know if all clones where indeed stopped except the fact original VI isn't editable.

Apart from the clone problem, I don't think this is a serious problem. I won't mind am optional "stop all" in the task bar though.

[JonP]

I disagree. When I perform the following sequence, LabVIEW does exactly what it is told and I am happy (BTW I am a fan of LabVIEW - normally):

1. Run a top-level VI.

2. Do something in the top-level VI that invokes a modal dialog.

3. Dismiss the modal dialog, the top-level VI continues to be interactive and all is well.

BUT if you dare to have the modal dialog open (but inactive) before you run that sequence step 3 behaves completely differently: although the dialog has supposedly exited it continues to hog the modality, if you get my meaning, and LabVIEW becomes completely unresponsive. If LabVIEW doesn't behave the same in both circumstances I can't see why that isn't a bug.

[wiebe@CARYA]

>If LabVIEW doesn't behave the same in both circumstances I can't see why that isn't a bug.

It does behave the same, and completely as expected. A modal VI acts like a modal window if it's not idle. So running a main VI renders a sub VI not idle, even if the sub VI is not being used, and it becomes modal.

A pain for sure (in this use case), I agree, but very consistent.

I don't see that as completely different behavior. The mistake you are making is that you link the window behavior to the run state. It doesn't need to be actively running or executing for the window state to be active, it just needs to be not idle.

It's just not convenient in your use case, but I bet there are use cases where it is. Splash screens and such for instance...

[JonP]

Well we must agree to differ. In my view, if a VI has exited it should relinquish its modal behaviour, even if it is still "not idle" by some NI definition. The splash screens I have implemented exit after some number of seconds, I would not want labview to hang if I had one open in the dev environment while running the main VI. As Mrs May might say, "exit means exit" .

If there really is a case where it would be useful for this to happen a) how would the user ensure it continues to happen when not running in the dev environment and b) I suggest it is an edge case and should be enabled by an option on the VI.

[wiebe@CARYA]

Not saying it's not inconvenient, but it is consistent and how it's designed. So, no bug, just inconvenient (sometimes, often, to you, and sometimes even to me).

[crossrulz]

You guys are just arguing semantics.  Yes, it is annoying behavior and I would put it in the realm of a bad design decision.  That does not make it a bug since it is behaving as the specification states.  The point of this idea is to get around that bad decision.  JonP, here is the idea you really want implemented: Change default behavior of Modal VIs.  Go give it a kudos.