LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

New option for window modality

The issue of a modal window being left open during debugging, only to jump to the front when the top level vi is run, has been an issue in LabVIEW for as long as I can remember. I am certian that every developer at one time or another experiences this behavior. There are several work arounds to this issue such as "the old 3 fingered salute" (CTRL+ALT+DEL) and kill LabVIEW, programmatically setting the window modality, external VI task managers, etc... however all of them are workarounds to deal with the issue.

 

The crux of the problem is that any front panel specified as modal immediately becomes modal as soon as the VI is reserved for execution. This proposal would establish additional option to the VI properties dialog (Modal when Executing). Which would only initiate the modal property of the window when the VI was actually executing.

 

Modal When Runing.png

 

There have been several similar ideas related to dealing with window modality (see below) however I believe this implementation is different than anything I was able to turn up in a search.

 

Related topics:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-Properties-Window-appearance-In-development-mode-po...

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Abort-VI-dialogs-modal-windows/idi-p/983168

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-Task-Manager/idi-p/920067

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-quot-Close-all-executing-VI-s-quot-menu-item-in-La...

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Abort-all-VIs-Button-in-Taskbar-Modal-Windows-Problem/...

11 Comments
Knight of NI Knight of NI
Knight of NI

Seems like a reasonable solution. I would also suggest that VIs imported from old versions with the modal option should be set to this new value.


___________________
Try to take over the world!
Proven Zealot

This sounds like it would be better to just outright change the behavior of "modal". Would such a change cause difficulties in some applications?

Active Participant

I had originally thought of proposing a change in the default modal behavior as I couldn't come up with a single instance where I might want the current default behavior.

Example Gatekeeper

I would support changing the behavior of the existing "Modal" option. I'd be interested to hear what kind of application (if any) that change would adversely affect.

DNatt, LV R&D
Proven Zealot

Big vote from me to change the current implementation.

 

Any problems it might cause is more than offset by the problems it will solve when actually programming.

Member

This change is a great idea.Smiley Happy

 

And, this problem with modals during programming is why I always have an EasyVIAborterAuto.vi on my desktop.  No more killing LabVIEW to recover from leaving a modal VI open.

https://decibel.ni.com/content/docs/DOC-2309

Systems Engineering
LabVIEW 5.0 - 2018
Active Participant

More virtual kudos for the change!

 

gsussman (or AQ): Could you raise that as an idea? I almost didn't make it to the comments here as the original idea seemed like a bit of a hacky solution... 

--
Chris Virgona
Active Participant
Example Gatekeeper

gsussman, do you want me to close out this idea as a duplicate of the new one? I don't have a way to transfer the kudos...

DNatt, LV R&D
Active Participant

The consensus seems to be that changing the current functionality is the correct thing to do.

Go ahead and close this idea and mark it as a duplicate...it's not like it has hundreds of kudos. If the idea has merit, I think the new one will generate enough support on it's own.