Change default behavior of Modal VIs

[gsussman]

Modify the default behavior of modal VIs to preclude them from becoming modal until the VI is actually executing, as opposed to the current behavior of becoming modal as soon as the vi is reserved for execution.

This prevents modal front panels that are left open during debugging from jumping to the front as soon as the top level calling VI is run, necessitating workarounds like killing LabVIEW via the task manager, the use of custom "Abort" VIs, or setting the modal property programmatically.

This idea is essentially a mutation of this one: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-option-for-window-modality/idi-p/2598027

[JÞB]

OK I'll say it one more time.  Modal means Modal to the application opening the panel.  In the words on John Gault "A is A."  The Window behavior property is run time writeable.  So, better practice (IMHO) is to handle the property within the vi (which even gets you an added possible hook to Float a GUI while running the UTF and Modal it in your app.

[gsussman]

I understand what you mean about the programmatic handling of window modality but following that train of thought, why are any of the selections for Window Behavior included in the VI properties? Why not make all of these setting programmatic only? The general reason is that it provides a convenient place to set these window properties without the need to completely understand the entire VI Server framework. This gets LV users up and running faster.

The issue stems from the fact that for users that opt not to use programmatic toggling of modality, LV will essentially generate a deadlock condition where you either need to kill LabVIEW or use some fancy "workaround" tool to get your development environment back. I would say that while that behavior may be how it is designed, it certainly seems to toe the line between design feature and bug.

I still haven't seen anybody post a use case for the current behavior.... so if nobody can come up with a condition, where this behavior is beneficial or necessary, then why maintain it?

[JÞB]

Let me draw another analogy or two.

Take the Stacked Sequence Structure.  Its there because its always been there functions in a known way and is consistant with the expectations of LabVIEW programmers coming to LabVIEW from other IDEs.  I can't tell you how long ago I last used one.  I have found better practices to get the same code written with some advantages I feel are valuable.

The Windows Propery configuration page follows the same paradigm.  Easy and intuitive to understand.  But, as you pointed out a developer can run into drawbacks that are frustrating by relying on this method THAT ONLY HARMS HIMSELF!  Yup, those required 3-finger solutes only happen when the developer does something during development.  Since any properly released application is unaffected the short-cut of using only this page is a valid development process.

What you are asking for is the equvallent of "A gun that will not fire when I aim it at my foot - If I know the secret safety setting."  While you can certainly use the "Programmatic" technique to build your dialog vit framework to pull all of your firing pins before the vis you develop on your model go idle.  Moreover, you can adapt and customize even further to meet your specific groups needs requirements and desires.

[Darin.K]

I actually dream of the day where VIs run in their own context, separate from the IDE.  Modal becomes modal to your app (ie. project or hierarchy) and does not take over LV.  Crashes in your code leave the IDE unscathed.  More like other languages in this regard.  I can crash my C++ program repeatedly and Visual Studio simply laughs at me.

[JKSH]

---

@Darin.K wrote:

I actually dream of the day where VIs run in their own context, separate from the IDE.  Modal becomes modal to your app (ie. project or hierarchy) and does not take over LV.  Crashes in your code leave the IDE unscathed.  More like other languages in this regard.  I can crash my C++ program repeatedly and Visual Studio simply laughs at me.

---

+1

---

@JÞB wrote:

Modal means Modal to the application opening the panel.

---

The current modal window behaviour is a result of too much coupling between the VI and the IDE.

• Having code visible should NOT be equivalent to having the code running.
• An application's modal dialog should prevent me from interacting with other windows from the same application. But, the IDE (and other projects) should NOT be considered part of the same application.
• If a running application misbehaves (e.g. due to programming errors, which is normal), it should NOT take down the entire IDE with it.

[Thoric]

I like Darin's idea of dislocating the application context from the IDE, such that LabVIEW is unaffected by the contained modality of your VIs.

On the original idea, I also like this so have voted this up. It's an alternative to my idea on having a VI Task Manager to allow you to select blocking modal VIs and change their modality, or just kill them (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-Task-Manager/idi-p/920067)

[altenbach]

Another possibility would be to automatically close (&defer changes) all subVI panels that are "Modal&set to show panel when called" when the toplevel caller is run, then only show them when called. This reproduces the typical state.

(old idea, I know, but this problem popped up again)