LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Start asynchronous call, reentrant execution

Solved!
Go to solution

I use a very minimalistic dialog VI showing only a Gauge indicator on its front panel. Here is the snapshot of this VI:

 

Gauge_dialog_BD.png

 

The purpose of this dialog is that, the user can pop up a larger size gauge indicator via clicking on the menu selection of one of the many indicators on the main VI front panel. The window behaviour is set to "floating", and I use the "Preallocated clone reentrant execution" so the user can launch as many dialogs as necessary. This is the place where I call async these dialog VIs:

 

MAIN_toplevel_BD.png 

 

Everything works as I expect, however I have some questions, someone might help...

  1. In the dialog subVI i properly close all used references, like the CtrlRef of the indicator where the user selects (menu selection) the dialog type (later I will also create a "minichart" type dialog beside the gauge indicator dialog). So I think this part should be OK, cannot create memory leak. Another thing I should decide, what execution mode should I use for these dialogs? The "Shared clone" or the "Preallocated clone" reentrant execution mode?
  2. Partly connecting to the first point, I wonder how I could refine this dialog pop-up feature. I mean, right now the user is able to pop-up arbitrary number of dialog windows showing value of the very same indicator located on the main front panel. What would be the best technique to detect if the user has ALREADY launched that specific indicator dialog, and instead of launching another, maybe just bring the already runnning dialog to the front and centered?

Thanks very much for any advice!

Best Regards,

0 Kudos
Message 1 of 6
(3,348 Views)
Solution
Accepted by topic author Blokk

@Blokk wrote:
What would be the best technique to detect if the user has ALREADY launched that specific indicator dialog, and instead of launching another, maybe just bring the already runnning dialog to the front and centered?

 


In similar "popout" functionality, using a messaging system,  I send a message to all popouts that is basically "Are you showing this reference? (and if you are bring yourself to front)".   Then I wait for all replies and if they all say "No" than I launch a new popout.

Message 2 of 6
(3,326 Views)

Hmm, sounds good, but then I have to extend the recent UserEvents functionality. I think just now, as a shortcut, I will create an FGV where I store the string labels of all running dialogs. When the user tries to launch a dialog, I just check whether the required string is in the string array stored in the FGV. So avoiding extra UserEvents to send there and back.

 

By the way, the execution mode is OK in this case?

Thanks!

0 Kudos
Message 3 of 6
(3,318 Views)

Actually I had to use your idea as well, so what I do, I use the FGV to store and check if a dialog is already running or not, if it does, I send a UserEvent command beside the ItemTag and the CtrlRef values to all running dialogs. All running dialogs check which one of them corresponds to the sent ItemTag and Ctrl value, if so, it brings itself to the front center of the actual screen.

It works very nice.

Thanks! 🙂

0 Kudos
Message 4 of 6
(3,277 Views)

@Blokk wrote:

By the way, the execution mode is OK in this case?


I don't think Shared versus Parallel Reentrant makes any difference to 0x80 Open VI ref, which makes a new clone regardless.

 


@Blokk wrote:

 I think just now, as a shortcut, I will create an FGV where I store the string labels of all running dialogs.


Personally I never use FGVs, but I've put effort into reuse code to make messaging easier.

 

 

Message 5 of 6
(3,263 Views)

Here is the code to message all Popouts and see if any one replied that it was already showing the item requersted (a VI, in my case):

 

Popout Window Query.png

 

0 Kudos
Message 6 of 6
(3,236 Views)