08-13-2020 10:25 AM
Try this; it is a non-blocking modification. I added your "counter" to the info window, to show how to update the info itself.
08-14-2020 03:43 AM
@pjroland1121 wrote:
Use a "Static VI Reference" to the VI you wish to call Asynchronously. Wire the reference to a property node for the "Execution State" (read). The enum provided will tell you if the VI is idle, bad, running, or running as top level.
See "Execution:State Property" in the LabVIEW help.
If you are interested, i'd recommend you look in to the Delacor QMH (DQMH) toolkit (free on VI Package Manager and listed on NI's website as well). It sounds like some of the things you are interested in trying are native features of DQMH.
It is an extension of the QMH architecture and has been presented at NI week a few times at least. Their built-in project template for "Continuous Measure and Log" helps understand how it works quite a bit. https://delacor.com/products/dqmh/ (they have documentation, videos, and even a youtube channel).
Yes I've heard of the DQMH, a friend of mine highly recommended it but I didn't have the time to try it yet.
However I didn't know it was free 🤔 Makes it even more interesting considering NI prices baseline.
I'll give it a try ASAP.
08-14-2020 04:42 AM
Actually I've found a much easier (but also dumber) way to do it thanks to this thread
Just need to get rid of any controls, Tick "Open Front panel when called" and untick "Close afterward if originally closed" and statically call the VI.
+ Super easy and fast;
+ Manages "multiple execution" by itself (if the user click again while the VI was already running, it just brings to the front)
- Works only to display some text and fixed images, nothing slightly more complex.
- I don't learn much more about VI dynamic calls 😅
08-14-2020 05:05 AM
@VinnyAstro wrote:
I've actually found a somehow easier solution:
In the options when opening the VI reference, I used 0x100 ionstead of 0x80.
This automatically closes my Info VI when closing the application.
However, if the user clicks multiple times on the info button without closing the subVi in between, then the subvi will reopen the same number of time after every close. And I guess the only solution is to indeed use either a notification or a global variable.
I'm quite confused though why the "Exec.state" always show "running". Any explanations ? Because all of the solutions above sounds like random bodging to overkilling, rather than a clean solution, no ? 🤔
Instead of starting it every time you can e.g. start it minimized in the beginning and send Events or Queues instead and it can open itself. In this case extra "open info" would be processed and do nothing as it's already open. You just need to Catch the "window.Close"-event so you can ditch it and turn it into a minimize instead.
08-14-2020 10:02 AM
Is this what you want?
08-17-2020 02:32 AM
From my original thoughts, not really.
But as I said above (msg 13) what you're proposing is actually what I'm going for in the end. I just unticked the option "Load when loaded" in the option Window appearance tab. But thanks for taking the time.
I'm just still genuinely confused why a simple solution implementing a button "Close" in the subVI exists.
The "one Button Dialog Box" VI does this, problem is, it is blocking...
Anyway, I'll just make some changes here and there.
Still open for suggestions involving a button in the subVI to close the window without blocking the main and without creating a parrallel loop just for it 🙂
Vinny.
08-17-2020 06:43 AM
@VinnyAstro wrote:
<snip>
Still open for suggestions involving a button in the subVI to close the window without blocking the main and without creating a parrallel loop just for it 🙂
Vinny.
You're going against the basic principles of dataflow. Either it needs to block, or it needs to be in a parallel loop. (Or it needs to not work.)
08-17-2020 07:00 AM
@billko wrote:You're going against the basic principles of dataflow. Either it needs to block, or it needs to be in a parallel loop. (Or it needs to not work.)
Hmm I haven't thought of that.
But what about the asynchronous calls then, isn't it the point of it ?
08-17-2020 07:08 AM
Your only issue with the asynchronous call method was that the user could press the help button multiple times and multiple windows would come up, right? Or was there something besides that?
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
08-17-2020 07:52 AM
@FireFist-Redhawk wrote:
Your only issue with the asynchronous call method was that the user could press the help button multiple times and multiple windows would come up, right? Or was there something besides that?
Yep.
I thought of disabling the button when the window is open, but I kinda didn't want to do that. My idea behind it is that if the user have a lot of windows open at the same time and don't want to bother finding the info one, then he can just click again on "info" and the info window would: 1. If it is not open, open in front; 2. If already open but minimised/hidden somewhere, Pop-up in front (and not re-open again)
I might be nit picking here, but I feel that it would be a normal and most natural behaviour from an application showing a poping window : Opening/showing up on a click on a button and closing ether by using the cross or clicking on closing button.
Also, the thing is, for now I'm doing this for a relatively easy application, which is just opening a window displaying a static message, but later I will most probably have multiple windows displaying various dynamic informations. I just figured out that training first on a simple application would be better 🙂