So if I can't store tabs in array or cluster controls...

[Daklu]

I have an application with several tabs each of which uses the same controls. Functions change depending on what tab is active. To simplify coding I created a single cluster of front panel controls and put it on (as opposed to in) the tab control. Now I have only a single copy of each control and I can direct the program flow by getting the value from the tab control.

Each tab needs to remember the state of all the controls the last time it was active so when the user switches back to that tab all the settings and values are the same way they were left. To be "smart" I bundled the tab control (which I typedef'd) with the cluster of front panel controls and put that in an array constant on my block diagram. Each element correlates to one tab on my tab control. I use the tab control in the array element to identify which tab that element is storing information for.

This works great until I tried to create some sub VIs to handle lower level chores. It turns out Tab controls/indicators can't be put in arrays or clusters. (But Tab constants can...) So my question is, is there a better way or "best practice" to store tab states? I thought about creating an enum typedef with just the tab names, but if the tab control or tabname control get out of order subtle bugs will be introduced that may not be noticed for quite some time. I've worked around the issue for now by pulling the tab state element out of the array before sending it to a sub vi but it's not an ideal solution.

[crelf]

QUOTE(Daklu @ Feb 7 2008, 01:04 PM)

This works great until I tried to create some sub VIs to handle lower level chores. It turns out Tab controls/indicators can't be put in arrays or clusters. (But Tab constants can...)

Right - the tab control/indicator is just an enum that other controls can bind to on the front panel - that's really the only relationship they have. The tab constant is a block-diagram-only node, so it's not bound to anything else, so it can be freely used as an enum constant.

[Daklu]

QUOTE(crelf @ Feb 7 2008, 10:40 AM)

Right - the tab control/indicator is just an enum that other controls can bind to on the front panel - that's really the only relationship they have. The tab constant is a block-diagram-only node, so it's not bound to anything else, so it can be freely used as an enum constant.

But the fundamental problem is I can't use that enum in an array as an input to a sub vi, because tabs can't be in an array unless they are a constant. (And of course they aren't constants when they are a sub vi control input.) I'd like to have the advantage of using the tab enum in my sub vi's AND I'd like to use my tab state array in those sub vi's. They appear to be mutually exclusive desires. Is there a good work around?

[Yair]

Maybe it's just me not understanding, but if the controls are all hovering over the tab control, what use does the tab control have? Why not just use a bunch of buttons or a listbox to indicate which "page" was selected? Can you post an image of the FP?

[Daklu]

QUOTE(Yen @ Feb 7 2008, 11:47 AM)

Maybe it's just me not understanding, but if the controls are all hovering over the tab control, what use does the tab control have? Why not just use a bunch of buttons or a listbox to indicate which "page" was selected? Can you post an image of the FP?

Why? Primarily it's a ui asthetic design issue. Plus buttons wouldn't give me the advantage of an enum. I could use an enum with a drop down box, but it's not really the right control from a ui design standpoint. (Switching tabs shifts data categories. Switching the alias, also a drop down box, changes the data within the category. Switching data categories is a bigger change and should be reflected in the ui.)

Also, since I've already structured my program around tabs I'm reluctant to go back and change it. I suspect it wouldn't be that big of a deal but I'd rather not.

Now lets see if I can attach an image...

[Yair]

The tab looks reasonable, but could also be implemented using any number of tricks. In any case, if I understand what you want correctly, why not just use the numeric value of the tab? Since the tab can't change, there shouldn't be any bugs and since you shouldn't care about the actual value (only the VI which does the caching needs to), there is no actual need to have it as an enum.

If this doesn't help, I suggest you post a piece of code displaying the desired functionality.

P.S. This is unrelated, but you should avoid mixing LabVIEW and system controls, since system controls can change with OSs, OS versions and OS themes and make your UI look weird if they are mixed with controls which don't change.

[Doon]

QUOTE(Daklu @ Feb 7 2008, 11:04 AM)

Each element correlates to one tab on my tab control. I use the tab control in the array element to identify which tab that element is storing information for.

Hiya, Daklu

I remember doing something like this a while back. I was wondering if you needed the enum at all. I had done something similar (tab controls and a cluster). In my implementation, I used the tab control to index the a cluster array. That way, each element corresponded to the tab position (i.e., Tab 1 = element 0, Tab 2 = element 1, etc.).

The only problem I can foresee in my implementation is if something were to rearrange the array -- otherwise, smooth sailing.

happy coding!

-H

[Daklu]

QUOTE(Yen @ Feb 7 2008, 12:55 PM)

Since the tab can't change...

There's the rub. This is for a piece of test equipment that will very likely need to be expanded in the future... near and/or far. It is probable that someone else will rearrange the order of the tabs. Since I reference the tab value all over the place it would be easy to miss a required change somewhere. This really isn't *that* big of an issue. I have a work around in indexing the tab control out of the array before I send it to a sub vi. Mostly I'm trying to make it idiot-proof when it comes to maintenance and expansion. (It's pretty embarrassing to break your own code and not know why. Or worse, break it and not know I broke it.)

Thanks for the system/Labview control tip. I'll be sure to change it.

QUOTE(Doon)

The only problem I can foresee in my implementation is if something were to rearrange the array -- otherwise, smooth sailing.

Ding! I know some idiot (like me) is going to change things around and screw it up. Like I said, not a big deal. It's just easier to maintain and understand my code.

As I sit here and think about your post, I realized I'm trying to make my data self-aware. If my data knows what it is, then my sub vi's and process loop states can operate on them correctly rather than requiring me to tell it what's coming. I have no idea if that's a good idea or not... I didn't even realize I was it doing until now. I'll have to think on that for a bit.

[jzoller]

How about serializing the state of the controls on each tab to a scratch file?

You could use something similar to the OpenG Read Panel from INI/Write Panel to INI (or XML or whatever) when you detect a tab change.

If you don't store the state of the panel between program modifications, there shouldn't be any problems with mis-naming or bad ordering.

Make sure you don't run into file write permissions problems if you do it this way!

JZ