BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

It has been a while since I've written code in "C"


@johnsold wrote:

CRTL + . does not work on VIs which do not have an abort button. It also does not work on modal VIs. There may be other combinations as well.


More generally, any keyboard shortcut where the corresponding menu entry has been removed from the runtime menu will no longer work at run time.

Message 11 of 15
(5,275 Views)

@Hooovahh wrote:

Oh sure, CTRL + . doesn't always do what you want.  Here is a fun one.  Create a subVI that has the window appearance setup to be a dialog which a modal display.  Then place that subVI in a main VI in a case structure, in a while loop.  Add a boolean control set to false on the case selector, and have the model dialog subVI in the true case.  Then open the front panel on both VIs before running the main. (with a constant on the while loop to not stop).

 

What do you get?  Well the model dialog is in memory so it is shown, and it is model so it is brought forward.  But it never is running so CTRL . won't stop it.  Also being model you won't be able to click into the Main to stop it, or CTRL . into the main.

 

The solution?  Task kill LabVIEW, or use some kind of Abort All similar to this one.

 

http://lavag.org/files/file/117-abort-vi/


Brian,  That's a damned dangerous vi.  Please do not promote it.

 

 

OK everything left-------

use this instead

Modal 1.png

 

I will rip throats out if a vi is saved with "Dialog" settings

 

Someone might not know what "Abort.vi" or "Revolk all Modals.vi" does with its private methods and drop it in a TestStand model.  Then hit "Save"

 

BAD JUJU

 

 

 

 

 

 


"Should be" isn't "Is" -Jay
Message 12 of 15
(5,265 Views)

@JÞB wrote:
Brian,  That's a damned dangerous vi.  Please do not promote it.

  [...] 

 

   I will rip throats out if a vi is saved with "Dialog" settings

 

   Someone might not know what "Abort.vi" or "Revolk all Modals.vi" does with its private methods and drop it in a TestStand model.  Then hit "Save"

 

   BAD JUJU


Please help me understand.  The only danger I suspected when releasing it was the need for it to run when opened, which I purposely didn't set.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 13 of 15
(5,235 Views)

@JÞB wrote:

Brian,  That's a damned dangerous vi.  Please do not promote it.

 


I think you should clairify what you believe is dangerous.  One could interpret your post as stating the Abort VI is dangerous, and what I believe you mean is the model VI that I described is dangerous.  

 

I'd like to post it so others can see how it can be a bad thing, but you said not to promote it.  Personally I don't see a problem posting a dangerous VI, as long as you know it is dangerous, and to close all code you care about before trying it.  I mean it won't corrupt files, or destroy your install, it just locks up a program, and task manager can fix that.

 

But yeah I agree, setting the window appearance to Dialog is just asking for trouble.  I think in the last 3 years I've made only a couple model dialogs, and I am fully aware of what thye are, so to not have them open when running the main.

0 Kudos
Message 14 of 15
(5,223 Views)

I haven't used anything other than the FP.Behavior and FP.Closable property nodes INSIDE the vi since I watched a co-worker blow up a TestStand model he was debugging and all of the pop-ups stopped pop-ing up.  some rocket scientist had put a version of that vi in the pre-UUT loop callback.  without bothering to explain that this would change the behavior of any dialogs that were accidentally left open when you hit F5.

 

since FP.Behavior and FP.Closable are run-time writable, just use them and save yourself a few headaches.

 

I even have a CTOTW for that. (Attached)


"Should be" isn't "Is" -Jay
Message 15 of 15
(5,213 Views)