Debugging modal windows using probes

[rawlukn]

While debugging a VI that is 'modal' (Modal Window Behaviour property is set) if I have it open in LabVIEW when I run the 'main' VI (Default Window Behaviour) that will call the 'modal' VI then the 'modal' VI prevents access to the 'main' VI.

This behaviour makes some sense because a 'modal' window is supposed to prevent access to the windows behind it. However, this is problematic when debugging the 'modal' VI: I cannot use a probe to monitor on the 'modal' VI while it is running as part of a larger application. To have a probe I need to have the 'modal' VI open in LabVIEW but it then prevents access to the 'main' VI once I run the 'main' VI.

What have you done to work around/with this issue when debugging modal VIs? Is there a way to prevent a 'modal' VI from taking control until it has actually been run?

It seems like a fundamental enough problem that I am surprised have not encountered it already or found a good solution on the forums. Thanks!

[P@Anand]

Simple solution would be to have a breakpoint in the Modal VI (Probably at the error in) and then use the probe to debug.

[rawlukn]

---

P@Anand wrote:

Simple solution would be to have a breakpoint in the Modal VI (Probably at the error in) and then use the probe to debug.

---

That is a good point. It does allow access to placing probes. I forgot that break-points were saved in the file.

However, it's not an ideal solution because everytime I'm done running I'll have to close VI and thus loose my probes. For more persistent errors that I need to test with a lot of data this means I'll have to re-add all the probes each time. Also, unless I step through the code I loose control over the probe window because the modal VI prevents access.

Any thoughts on how to make the probes persistent?

[JÞB · Accepted solution]

Another option is to create your dialog vis with some features that avoid potential pitfalls.

Many of you will recognize this code is based on the Prompt User for input VIT that is under the prompt user express vi. You might note I based it on events rather than polling.  Why, because I don't personally care for the polling while events are available in all LabVIEW versions these days!  I keep a set of vis and a vi template around to allow me to create code easilly that handles some of the common modal vi challenges.  like OMG its open and not running when I reserve it!  Or, how can I do a Unit Test on it?

Working on debugging a set of "Modal" vis that are not based on a framework designed for debug compatability is your real problem here.  hang it on a better framework and now you can solve the little issues you need to.  Put that framework in the proper location and remember File>>New... From Template>>> is your very good friend.

[rawlukn]

---

@JÞB wrote:

Another option is to create your dialog vis with some features that avoid potential pitfalls.

Many of you will recognize this code is based on the Prompt User for input VIT that is under the prompt user express vi. You might note I based it on events rather than polling.  Why, because I don't personally care for the polling while events are available in all LabVIEW versions these days!  I keep a set of vis and a vi template around to allow me to create code easilly that handles some of the common modal vi challenges.  like OMG its open and not running when I reserve it!  Or, how can I do a Unit Test on it?

Working on debugging a set of "Modal" vis that are not based on a framework designed for debug compatability is your real problem here.  hang it on a better framework and now you can solve the little issues you need to.  Put that framework in the proper location and remember File>>New... From Template>>> is your very good friend.

---

Indeed. It is a problem with the framework. I was hoping that I had missed something in the default tools provided in LabVIEW before creating a framework to work around the problem.

My other workaround thougt was to make the VIs have a 'default' behaviour when running from source and change them to 'modal' when built to an EXE since that is the only time it is really necessary.

[JÞB]

Yes, I've used the same thing with a select drive by App.kind = "Runtime Engine" (or a conditional disable structure)

[rawlukn]

After experimenting it seems that the most useful workaround is to change the VI mode to modal when the VI is run and set it back to default after. Thanks for the suggestions Jeff.