From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Asynchronous call: Checking if the sub-VI is running.
@VinnyAstro wrote:
@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 🙂
Well, don't open a new VI reference each time. If you reuse the 1st one, it'll refer to the same window. 🙂
Check this out and see what you think. Essentially, you build out the logic in your main VI to do different things based on if the help window is already open or not. And in your help window VI, take the queue from your main VI as an input so when user closes help window, you can update a Boolean flag (which exists in the data cluster of your main VI) that stores whether the help window is running or not.
First three images are in main VI, last is in help window VI.
Just to complicate things a little bit, you could always make the choice to display the pop-up as a choice in a custom menu. If a menu event occurs, it is determined that the menu item changed, and it is selected (has a check mark) display the pop-up, if no check mark, don't display it. That way, you won't have to worry about multiple button presses. As a cleanup, you can programmatically uncheck the menu item to trigger the event to close the pop-up.
@VinnyAstro wrote:
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.
🙂
This isn't nit picking at all. From a UX perspective (and IMHO), that is the best possible way of handling a help window. And that is basically how Detailed Help in LV works too. I would hate if it opened a new window everytime.
