Using tab control while VI is running

[spaceboy]

hi,

I'm using LabVIEW v6.0. I have a VI with a tab control. The user must be able to switch between the pages during runtime. For some reason I'm unable to do this. I can only switch when the VI is not running. Is this built in or am I overlooking something? Is there a way to change this behavior?

thanks,

Jon.

[lraynal]

Can you check if the TabControl is an Indicator ? It would explain why you can't change the tab during the running...

So Right click on it, and "change to control"...

It should not modify the code around!

Tell us if it's enough, or send us the code!

Good luck,

Laurent

[Yair]

Another option is that the tab control is disabled (right click>>Advanced>>Enabled State), but I would agree the indicator option seems more likely.

[spaceboy]

QUOTE(yen @ Jul 23 2007, 09:15 PM)

Another option is that the tab control is disabled (right click>>Advanced>>Enabled State), but I would agree the indicator option seems more likely.

It's neither. This is very odd. I went back to work with an older version. At first I was able to switch between the tab control pages with no problem but after a bit of resizing of while loops it stopped working! Strange. The code is attached.

[Yair]

It seems to work fine in 7.1, even after playing with the size of the while loops.

I would guess this was some sort of bug which was fixed. Do you happen to have 6.0.2 which should have some bug fixes?

By the way, in general, there are several things I would change about how you do this.

For example:

• You can move the entire password part into a dialog subVI and use a boolean output for the status of the password. The rest of the code is in the True case of a case structure which only runs if the password status is T.
  Also, I don't think there is any need to inform the user that the password is correct since they will realize that when they see their program is running.
  
• You don't have any wait primitives in your while loops. This is very important because if you don't use them, LV will use all the CPU. This might even be the cause of your problem.
  
• Using the Stop primitive to stop the VI is bad. Instead, you should do what I mentioned before.
  

[spaceboy]

QUOTE(yen @ Jul 23 2007, 11:31 PM)

It seems to work fine in 7.1, even after playing with the size of the while loops.

I would guess this was some sort of bug which was fixed. Do you happen to have 6.0.2 which should have some bug fixes?

By the way, in general, there are several things I would change about how you do this.

For example:

• You can move the entire password part into a dialog subVI and use a boolean output for the status of the password. The rest of the code is in the True case of a case structure which only runs if the password status is T.
  Also, I don't think there is any need to inform the user that the password is correct since they will realize that when they see their program is running.
  
• You don't have any wait primitives in your while loops. This is very important because if you don't use them, LV will use all the CPU. This might even be the cause of your problem.
  
• Using the Stop primitive to stop the VI is bad. Instead, you should do what I mentioned before.
  

• This is just a demo. The real version has a sub-VI that verifies the password. Also, no dialog for a correct password
  
• I tried inserting wait periods into the while loops. Didn't help. I might have to (reluctantly) switch to LV8.0.
  
• To stop the while loops I could always have a master button that stops any while loop, but that would require a lot of local variables. Why do you think that's better than using Stop?
  

[Dirk J.]

QUOTE(spaceboy @ Jul 23 2007, 10:38 PM)

• ... I might have to (reluctantly) switch to LV8.0.
  
• .... a master button ... that would require a lot of local variables. Why do you think that's better than using Stop?
  

If you have the opportunity to upgrade, do so! The event structure greatly simplifies this kind of tasks, i.e. you can simple respond to Stopbutton.Click; Password.Valuechange and Tabs.Valuechange events.

Using Stop is not recommended because it, well, stops. Immediately. Without you ever having a chance to clean up stuff.

You might want to look into "state machine" VI architecture for your VI. I don't have any version below 8.21 available now, so I can't upload a VI, but here are some screenshots that may help you going. There are 4 states, some resembling the frames in your VI:

- initialize: stuff performed in 1st frame of your VI. after that, go to "poll".

- poll: checks the stop and enter password button to decide what to do ("quit" or "verify password")

- verify password: checks your password. if OK go to "rest of VI", if not, back to "poll"

- rest of VI: whatever you want to do more here

- quit: stops the VI. you could do cleanup in this state.

[Yair]

Using the locals is definitely better than using the stop primitive and as Dirk mentioned, a state machine architecture would probably help as well.

A more elegant option for stopping multiple loops (or even VIs) is to use a USR global, similar to the one shown by mballa here.

If you want a simpler version, you can simply have a VI with two boolean inputs like this and place it in the boolean wire. Stopping any of the loop will stop all the other loops.

http://forums.lavag.org/index.php?act=attach&type=post&id=6437

P.S. If you're upgrading, go to 8.2 or wait for the next version, which should come out soon. Don't get 8.0.