close a dialog interface after some predefined condition

[ericyuan]

So I want to pop up a dialog vi(a 10s timeout vi)some when running the test like remind the operator to push a button on the PCBA, and then i will detect whether the operator had pressed the button, if the labview code had detected the press action, then i will close the dialog and go to next test.
my problem right now is i can create a vi and set it as a dialog but i cannot close this dialog and have to waiting it timeout after 10 seconds. 

is there any good way to close the dialog in code.

So the first callback is pretty simple, will run 10 seconds and do nothing as below,

in the second callback,the only thing i did is trying to close the first call back. but of course failed.

and below is the main code

[ericyuan]

I also put the source file here.

[GerdW]

Hi Eric,

your "dialog" VI can wait for a notifier value.

Or wait for an occurance. Or an event. Or read a global variable and check it's status.

It can wait for any of those (or even more) options in parallel to its own 10s timeout…

[wiebe@CARYA]

AFAIK, Waiting in callback events will ruin all event handling for the rest of the application. Those callback VIs are prioritised pretty aggressively.... I wouldn't recomment it.

[ericyuan]

that's good to know, right now i don't have any other idea except a callback to realize this functionality, another solution is use a Global variable, which i think it's also not recommended to use? 

[wiebe@CARYA]

You can make the callback event trigger a user event or value change event. Then handle the event in a normal event structure.

Most of my callback events get refactored pretty fast. For .NET and AX events, callbacks are the only way, so they are exceptions.

LabVIEW Callback Events have some rusty edges. They are not 100% stable, especially when created in clones (multiple levels) and register events on subpanels (multiple levels) in clones. And the lock classes that have callback VIs, and you need to reload the project to continue development.

I usually dynamically start a clone VI with an event structure. With the right VI server settings, this VI will stop if the creator stops. This has several advantages. You have a normal VI handling all events. And it won't crash or hang LabVIEW. And it won't lock your classes with callbacks ("running in another context"). It's a bit easier to comprehend as well. A bit more work to setup though.

[drjdpowell · Accepted solution]

As others have said, do NOT use control callbacks.   I don't think they are even officially supported (unlike .NET callbacks).  

To "cancel" a dialog, try:

-- Create a Queue (doesn't matter what the data is)

-- Pass the Queue in to your dialog (which you launch asynchronously, not as a Callback)

-- have your dialog poll that the Queue remains valid

-- close the Dialog if the Queue becomes invalid

-- To cancel the dialog programmatically, just destroy the Queue

(side note: the Dialog should also kill the Queue as it closes, to be sure there is no Queue memory leak)

[wiebe@CARYA · Accepted solution]

---

@drjdpowell wrote:

As others have said, do NOT use control callbacks.   I don't think they are even officially supported (unlike .NET callbacks).  

To "cancel" a dialog, try:

-- Create a Queue (doesn't matter what the data is)

-- Pass the Queue in to your dialog (which you launch asynchronously, not as a Callback)

-- have your dialog poll that the Queue remains valid

-- close the Dialog if the Queue becomes invalid

-- To cancel the dialog programmatically, just destroy the Queue

(side note: the Dialog should also kill the Queue as it closes, to be sure there is no Queue memory leak)

---

That's what I do.

It is possible to setup VI server so a started VI stops existing if the creator stops running. But that doesn't work if the front panel is open, as that counts as a valid reference.

Also, I do this variation:

-- Create a Queue A (datatype is a queue of any type)

-- Pass the Queue A in to your dialog (which you launch asynchronously, not as a Callback)

-- have your dialog create a Queue B and enqueue it on Queue A

-- have your dialog poll that the Queue A remains valid

-- close the Dialog if the Queue A becomes invalid

-- To cancel the dialog programmatically, just destroy the Queue A

The caller now has the ability to monitor the dialog. If the dialog is closed, but even it it's aborted, Queue B stops existing. You can dequeue Queue B with or without a timeout to check if the dialog still lives.

Queue B can, but doesn't have to, contain dialog feedback.

Also: DO NOT NAME THOSE QUEUES!

[ericyuan]

Appreciate the help from you guys, I will have a try, but as right now,I think your commend can be regarded as the solution