A better way out of "programmatic close cannot be cancelled"

[altenbach]

If we have a project and only open a subVI, make some changes, then save it under a new name, LabVIEW will also update the calls of all other VIs in that project that depend on that subVI, even if they have not been opened.

As soon as we save the subVI under a new name, we get confronted with the following dialog and there is really no easy way out unless we exactly remember how that subVI is used in the various callers. Note that "cancel" is not available. At this point I always feel like I painted myself into a corner.

 

I would prefer another button that e.g. allows me to open the front panels of the affected callers to double-check the code. At this point I can then either save or close them as desired.

IDEA: I would prefer a new button on this dialog that could be labeled similar to e.g. "Open front panel of affected items". Pressing it would close this dialog and open the affected VIs, allowing me better control to decide what I want to do here (i.e. save or not save changes).

(... and analogous behavior if "apply same action ..." is unchecked, of course)

[altenbach]

One possible solution would be to make the [Cancel] button operational (i.e. not greyed out), but change the text next to it to "Open affected items for editing".

[altenbach]

Another solution would be to warn before actually saving the subVI so we can cancel at that point. For example we could get a dialog: "Saving the VI under a new name will also update the following callers ...." at which point we can OK or cancel. If we say OK, the dialog shown in the image above is no longer necessary. If we cancel, nothing happens.

(As we can see, there a obviously many (better!) ways to handle this differently. We should discuss the merits of the various suggestions. I am sure there are more ideas out there.)

[AristosQueue (NI)]

Unless you drum up a lot of support here, this idea fails AQ's "do not make the Save Changes dialog more complicated by adding more options" test and thus I would oppose implementation.

Corner case complaints about Save Changes, like this one, pale next to the onslaught of complaints that "there's still too many options that I have to read through." And unless you are *really* deeply versed in LabVIEW lore, there is no relationship between "save", "don't save" and "open panel".  Worse, we would *still* have to have the occassional "programmatic close cannot be cancelled" because the programmatic close may be happening on the project or app instance itself such that opening the panel is not an option because the whole environment has been told to go away. Actually, we would have to keep "Cancel" grayed out and leave the explanation *even if* we added the new button in order to explain why the [X] button, which has no text on it, is grayed out. It is a major usability no-no to gray out cancel without an explanation for why the user is unable to cancel -- worse than not letting them cancel in the first place, which is already very not good.

The solution to all of this seems to be more separation between source code and runtime environment. That's the only way I see that we'll ever get a more straightforward Save Changes dialog.

[altenbach]

> Unless you drum up a lot of support here, this idea fails AQ's "do not make the Save Changes dialog more complicated by adding more options" test and thus I would oppose implementation.

If you look at the suggestions in my second and third post, there are no additional options added. The idea in post #2 just keeps the dialog more functional by not blanking an existing option and giving it a more useful and appropriate function. The idea in post #3 prevents the user from getting trapped by giving an earlier warning that can be cancelled, all via a simple change in the internal order of operations.

The main problem with the current implementation is that the user typically has no idea why he gets that dialog (I did not for the first few times I saw this!) and there should be a way to get out of it until the issues can be researched in detail. It is not nice to be forced into a definite Yes/No answer with a modal dialog if we are not sure what's actually going on and what we actually want. The modal dialog cannot be cancelled and we cannot look at the code that's about to be changed as long as the dialog is there. I always feel trapped when I get it. (I even wonder if it violates some established UI guidelines.)

[AristosQueue (NI)]

> by not blanking an existing option and giving it a more useful and appropriate function.

I tried to address that. Option #2 still makes the dialog more complicated -- now you have a Cancel button that *does* something. How does that make sense? And, as I said, there would still be times when opening the panels isn't possible and the grayed out Cancel would still exist.

> Another solution would be to warn before actually saving the subVI so we can cancel at that point.

The Save As dialog already has this. If you pick Save As to "Substitute Copy For Original", why would you expect us to warn you that we're about to modify callers? You just asked us to do that, so it doesn't seem like something we would warn you about. If you didn't want to modify callers, pick one of the other two Save As-Copy options.

[AristosQueue (NI)]

> It is not nice to be forced into a definite Yes/No answer with a modal dialog

> if we are not sure what's actually going on and what we actually want.

This part I agree with. I agree it is a not good scenario. I just don't think the proposed cure is better than the disease in this case. A more radical cure would seem to be necessary, something that makes you much more aware of how your edits are affecting your code at all points, and a better "describe changes" link.

[altenbach]

Thanks. I don't claim I have found the best possible solutions, so any other suggestions are of course very welcome. 😉