08-19-2012 04:15 PM
Hello all,
I've a quick question. I have right now....a numeric constant...starts with "1" intially when starting the vi.
I use this as a shift register on my main while loop....as the counter to use when the user clicks various items on my vi. This tracks the order the user wants things to happen later.
It has now occured to me..that the user might not have selected all possible options, before quitting the vi....and might need to restart it...and begin to select other options...needing to keep place form when he left off last.
Of course, with how I have it set up no...when the vi is started...the counter is reset to "1". All the objects on the screen, are in the state it was when it was stopped...objects selected prior to quitting are still selected in the proper order...but if the user starts to select anything unselected..rather than starting at the next count..it starts at 1.
Is there any way, upon quitting..to set the initialization counter to whatever number was last in the shift register..so that when the vi is started again...it will start up where it left off?
Thank you in advance,
cayenne
08-19-2012 04:21 PM
Use a configuration file. When the user exits, part of your shutdown sequence should be writing all current values to a file. Then, when the program starts up again, load that configuration file, and select the values to load into the shift register.
08-19-2012 06:36 PM
A config file is certainly the way to go if you want to maintain state across a close-out and open-up of the VI and/or LabVIEW but since the problem was posed with the condition that "All the objects on the screen, are in the state it was when it was stopped..." when the VI is restarted, it's still all in memory and we can make use of that without the added complication of a config file. See if this makes sense to you...
08-19-2012 07:19 PM - edited 08-19-2012 07:20 PM
@Warren Massey wrote:
A config file is certainly the way to go if you want to maintain state across a close-out and open-up of the VI and/or LabVIEW but since the problem was posed with the condition that "All the objects on the screen, are in the state it was when it was stopped..." when the VI is restarted, it's still all in memory and we can make use of that without the added complication of a config file. See if this makes sense to you...
[...]
Would the First Call? function be useful in your example? (assuming that you would have initialised the shift register after the first call)
08-19-2012 08:07 PM
I want to clarify. I'm assuming you have a config window or something that you open and close, but you don't actually stop the program? However, if this is your main window and you are stoppping the program then restarting, in reality you should have the program actually exit. The user should never have to press the run arrow in an executable to keep it consistent with other windows applications. It's (generally) confusing to an end user if they click the "x" and their program stays open. Then they have to click an arrow to make it start again.
08-20-2012 09:00 AM
@James Mamakos wrote:
Would the First Call? function be useful in your example? (assuming that you would have initialised the shift register after the first call)
No, First Call does not help in this situation as it returns TRUE the first time it is called after any start and restart of a VI. We need something that only returns TRUE after the first start of a VI but returns FALSE on subsequent restarts. It's easy to build a subVI to do this using a functional global (uninitialized shift register in a one-shot while loop) similar to the examples I already posted.