LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Occasional Nugget 08/11/2008

Be very careful with that vi.

 

Darren, a good bit of that could be opened now. I do believe.

 

Now here is a story about one instance I saw most of that vi BD rewritten.  The VI was called "Revoke all modals" and really lacked documentation.  It was placed into a teststand model to ... well you guessed it, kill all open but not running modal FPs.  Then people saved............. and none of thier dialogs opened modal....and they wondered why.  Perhaps there is a super secret method off screen that disables the dirty dot and prevents saving the affected vis with the changed behavior.

 

BUT, FP.Behavior is run-time writeable!  so there really is no excuse to have a non-running vi with its FP behavior set to modal!  Period!  Let the dialog handle its own FP.behavior and leave it default while saved.  Caution, this comes with the same caveat that" Defer panel updates" does.  Don't abort the vis! the property is saved with the vi.

 

Of course you can always read Ed Dickens' sig line one more time..........

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 31 of 34
(2,161 Views)

When I close my project I get a dialog that says "Closing the project will abort some running VIs".  If I cancel that dialog and run the Abort VI from this thread, no VIs are shown in the Running VIs drop down.  If I then pull up VI hierachy, I can see the VI that didn't handle the shutdown event in time/properly.  The VI was launched by Asynchronous Call By Reference.  Any idea why it doesn't show up in the Abort VI drop down?  (There is nothing else to the right in the hierarchy image below.)

 

Error Handler Not Exiting.png


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 32 of 34
(2,072 Views)

 


Darren wrote:

...In the case of the Abort VI utility, I use some private properties to gain access to all application instances, then filter out those that are private application instances.  These properties, as LabBEAN mentioned, will probably never become public.


 

 

I ran the main VI which launched the Error Handler above from a LabVIEW project application instance.  The main VI exited properly leaving the Error Handler orphaned, as you can see by the heirarchy.  This only happens very occasionally and I'm trying to determine whether the fact that the orphaned VI isn't showing up in the "Running VIs" list created by your Abort VI utility could be symptomatic of some sort of unrelated bug (e.g. with ACBR).  Have you ever seen running VIs not post in your "Running VIs" list?

 

 


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 33 of 34
(2,019 Views)

@LabBEAN wrote:

 

Have you ever seen running VIs not post in your "Running VIs" list?


 

The Abort VI utility only shows VIs with an execution state of "Run top level". I'm pretty sure that VIs called by ACBR have an execution state of "Running". I'm guessing that's why you're not seeing the VI in the list.

0 Kudos
Message 34 of 34
(1,988 Views)