pop up dialog async call and forget

[Blokk]

Hello,

I do not really have experience with dynamic VI calls, so I would like to ask for some help.

Here is a (screenshot only) part of my MAIN VI, where I call a pop-up dialog VI using the "dynamic call and forget" method:

I only pass one reference into this VI, the ref of the pop-up button, so when the user closes the pop-up window, I re-enable this button on the MAIN front panel. This pop-up dialog functions as a Graph monitor, it can update its Graph using an ActionEngine which is a buffer. So please ignore the missing type defs and the ActionEngines, they are not relevant in this case. Find this pop-up dialog attached.

Actually my application just works, I only started to get some problems since when I included the "MGI Save & Restore Settings.vi" in this pop-up dialog, in order to save Graph settings to a config file (the application will be used as a built exe). When I close the pop-up VI, I can see the Graph settings are properly saved into the *.ini file under the "Documents" folder. However, when this file exists already, and I call this pop-up VI, I get the following error (so when the MGI VI is fired with the "Restore" action at the beginning of my dialog VI):

I have three questions:

1. What I do is it OK? I mean to pop-up such dialog, is it OK to use the "call and forget" method?
2. When the user closes the panel of the pop-up VI, does it stay in the memory? Do I have a memory leak, or it closes properly? (I think not...)
3. I do not understand the error produced by the MGI Toolkit VI, it has something to do with the dynamic call method? I even feed it with the static VI reference of the pop-up VI itself. Before I tried the "This VI" reference constant, but getting same error.

Edit1: hmm, maybe the MGI toolkit is not compatible with Graphs with multiple Y-axis?..I will test it...

[Sam_Sharp]

A few points I noticed:

- Using the call and forget method for launching custom dialogues is fine and something I do quite often - you just need to make sure that your called VI will shutdown correctly when your application closes (if they leave the dialogue open and close the software, for example)

- The VI is non-reentrant so it can only be loaded into memory/run once so there's no chance of memory leaks from opening multiple copies

- I usually use a Strictly Typed Static VI reference (right click the Static VI Reference) for getting the name/path and the VI Type Specifier - it makes sure that your ACBR node always matches the VI you're calling and cleans up the block diagram slightly

- The references you're passing into the MGI functions: "This VI" is definitely the right reference to use as it returns the reference to the clone/instance of the VI that's running rather than a Static VI reference which refers to the Original VI. In your case you can only have one instance of the VI running (because it is non-reentrant) so I don't think it matters here (but I'm not sure?!). I think this will fix the issues with the MGI functions. There's no difference when using the VI reference or This VI when it's a non-reentrant VI but if you were to ever make it reentrant and allow multiple copies to execute at the same time then you'd be better off using "This VI".

- I also suspect an issue around closing the VI reference after the ACBR node and having a non-reentrant VI but I usually use reentrant VIs and allow multiple calls so I'm not exactly sure of what happens in the non-reentrant case.

Edit: I've just tried to recreate your setup with the ACBR node for my own sanity and I cannot replicate the same issue you're having so I doubt it's related to how you're calling/running the VI and more about the MGI function.

[Blokk]

---

@Sam_Sharp wrote:

A few points I noticed:

- Using the call and forget method for launching custom dialogues is fine and something I do quite often - you just need to make sure that your called VI will shutdown correctly when your application closes (if they leave the dialogue open and close the software, for example)

If you have a look at the attached VI, if the user closes the FrontPanel by the "cross at top right", the VI will finishes running, yes? If this dialog is open when the user closes the top level MAIN VI, how should I check it and close the pop-up VI? I could maybe check if the dialog is open via an invoke node? So maybe the best would be not to close the VI Reference after the dynamic call, but store it in a shift register, so I can use it later...hmm, I am not sure what is the most simple thing here...

- I usually use a Strictly Typed Static VI reference (right click the Static VI Reference) for getting the name/path and the VI Type Specifier - it makes sure that your ACBR node always matches the VI you're calling and cleans up the block diagram slightly

I will try this.

- The references you're passing into the MGI functions: "This VI" is definitely the right reference to use as it returns the reference to the clone/instance of the VI that's running rather than a Static VI reference which refers to the Original VI. In your case you can only have one instance of the VI running (because it is non-reentrant) so I don't think it matters here (but I'm not sure?!). I think this will fix the issues with the MGI functions.

Hmm, me neither sure what is going on 🙂 But I already used the "This VI" constant, and the error was the same. Anyway, I try again, maybe I cannot remember 🙂

- I also suspect an issue around closing the VI reference after the ACBR node and having a non-reentrant VI but I usually use reentrant VIs and allow multiple calls so I'm not exactly sure of what happens in the non-reentrant case.

As the first point, I will only close this ref when I quit the MAIN application.

Thanks for the suggestions! I will post back. (i hope using bold is OK 🙂

---

[Sam_Sharp]

I made some edits to my post above after doing some experimenting around using ACBR for non-reentrant VIs.

I'm trying to avoid having to write out a really long detailed explanation of ACBR references but when I do what you're doing (albeit for multiple clones) I open the reference once at the start of my application (either outside of the calling loop or opening on first call and holding in a shift register) and then closing the reference at the end. The VI Reference coming out of the ACBR node depends on the method used to open the VI reference - it can either be a reference to the original VI (as it is with a non-reentrant VI) or it can be a reference to an instance of the VI.

Yes - your VI will stop running in the Panel Close? event case but what happens if they shutdown the application while the dialogue is open? (Answer: your dialogue will continue to run until *its* panel is closed) I normally pass a user event into the dialogue which is fired when my application shuts down to also tell the dialogues to close as well - basically you need *some* method of communication from the application to you can tell the dialogue that your application is closing and that it should close as well.

[Blokk]

Hello,

"I normally pass a user event into the dialogue which is fired when my application shuts down to also tell the dialogues to close as well"

thanks, this seems a nice way. Actually if the user quits the main application, and forgets to close the dialog window, he or she cannot start the main application again 🙂 So lets say they will be "forced" in this way to close that window too before restarting application. But I will do the user event method, it sound more sophisticated 🙂

Yep, I think the "bug" is in the MGI. I try to figure out what the problem is, and replicate the problem... Otherwise I will need to write my own config file subVI, which should not be too difficult, since I only need to save a few properties, not all (curve thickness, colour, etc..)

Thanks for the valuable info! 🙂

[crossrulz]

---

Blokk wrote:

"I normally pass a user event into the dialogue which is fired when my application shuts down to also tell the dialogues to close as well"

thanks, this seems a nice way. Actually if the user quits the main application, and forgets to close the dialog window, he or she cannot start the main application again 🙂 So lets say they will be "forced" in this way to close that window too before restarting application. But I will do the user event method, it sound more sophisticated 🙂

---

Yes, User Events are awesome for this situation.  I actually do not pass them in.  I have the User Events stored in an Action Engine so that anybody can generate the event without needing to pass around the reference.  I highly recommend an event for aborting/shutting down and second for allowing the dialog to tell the main when it has completed.

[Blokk]

I have managed to pinpoint the location of the error, see the attached VI. The MGI toolkit creates an error, if I have a cursor on this XYGraph. "Invalid property value: cursor list."  It is strange enough, even if the config ini file does already exists, you need to run TWICE the VI in order to get the error. So every second run does not create error, however neither functions properly, does not reset settings of the graph... 🙂

If you delete the cursor, no more error, all works fine.

I will try to investigate this further, but if someone will be faster, thanks! 🙂

edit: a funny workaround could be to save time: before Reset/Save settings using MGI kit, I programmatically delete the cursor, and after re-create it :))

[Blokk · Accepted solution]

Just FYI, I have mailed the MGI people, and they found the problem very quick 🙂 

Here is their reply:

" I've looked at the root cause for what you're seeing and uncovered a LabVIEW bug that I'll be reporting. Apparently LabVIEW is giving us a cursor xscale property of 65536, but that is an illegal value. We get the error when we give that value back. I've attached the VI that I'll be sending in to NI to describe the error.

I've also attached a replacement subVI that works around the issue. We'll release an update later after proper testing, but this works to fix the sample code you sent."

[bekateen]

Sorry to hijack a thread, but this seems like an appropriate place to pose a related question.  I want to run a subVI as a pop-up screen that remains active and accessible in a separate window from the rest of the main (calling) VI and then closes programmatically when the calling VI closes.  For now, the subVI is only an "About" screen for the calling VI, but eventually it will be a Help menu also. 

What I want to achieve is to allow the calling VI to run continuously for as long as a user is interacting with it.  At the start of execution of the calling VI, the subVI will appear in the upper corner of the computer screen and will remain active and interactive, without freezing the calling VI, until the user closes the calling VI using a STOP control.  

I am inexperienced with using the code described above to call and forget a subVI, so I do not understand how to translate the example above in order to apply it to my code.  Can you show me how?  

Thank you, Eric

[Blokk]

I had a look at your VIs (i insert here a snippet, so other people with mobile might contribute too the post):

First of all, You have several issues with the code. I really recommend you to take some training or tutorials (the Core 1-2 online training is very good!). Pay special attention how to program State Machines. As I see, you need to interact with user inputs, save data to file (maybe also to load?), you want your code to repeat certain tasks, etc. All these should be programmed with a State Machine. What you have now, is really not scalable, with these greedy While loops inside Flat Sequence Structures. Greedy while loop: you have loops, which wait for user interaction and iterating with the maximum speed thus "burning" the CPU. Put some (like 100 msec) Waits into such while loops! Or even better, learn how to use Event Structures!

Also might be problematic of your usage of local variables, but I did not check this closer.

Here you can find some good hints too: http://www.ni.com/newsletter/51735/en/

About your actual question: if you want your pop-up window exist during the total life-time of your top level application (main VI), then you could just simply use a subVI statically, no need for dynamic VI calls. What is important, to set-up a two-way communication line between the parallel subVI and the calling top level VI. Dynamic User Events are good candidates for such task, but since you use LV2017, you could even solve this using Channels, like Messengers or Streams. But in this case I would prefer User Events, so you would have an Event Structure inside the pop-up subVI, and also one in the top level VI.

Do you need any data exchange between this pop-up window and the main VI? If not, just send a Stop command to the pop-up via a Queue or a Notifier, or a Stream, etc...