Typedef Tab question

[X.]

A quick search with "Typedef Tab" did not return an answer to my issue, so here it is (tested in LV 2012/Windows XP).

As I was reading this thread looking for ideas, I rediscovered something I had used in the past, that is, typedefining a Tab control in order to have an easy way to programmatically flip between tabs by wiring a (tyepedef) enum to the tab "Value" property node.

[As a side note, when you do so, a type conversion dot appears, as Value property nodes apparently still don't remember that they are attached to a typedef (see here)].

Obviously, I did not fully explore this approach in the past, as I just ran in an little problem. Here is how it goes:

1) Create a Tab control and populate the two default tabs with various controls. For instance, put a numeric in the first tab and a string in the second

2) Now, typedef this Tab control and open the typedef.

3) Insert a new tab (Tab 3) in between Tab 1 and Tab 2. Apply Changes

4) Go back to your original diagram: now Tab 3 has the content of the original Tab 2 (a string) and Tab 2 is empty.

I would argue this is a bug in the sense that this is not what I intended to do: I wanted the newly created Tab to be empty so that I could populate it with new controls/indicators.

More problematic: I don't even know how to achieve that goal without renaming tabs in the typedef and rearranging their order.

Comments welcome, especially from NI.

[JÞB]

Just another reason why I HATE TABS.  A type def f a Tab control only defines the container NOT the contents.  This is why you get undesired (not unexpected) results when you add panes (Tabs)

Better to use sub-panels controlled by a radio button as seen Here

[JÞB]

I know I'm going to need to defend that statement again so here goes.

This container (Miss)named the Tab Control allows the developer to create several panes showing multiple logically related groups of objects.  (At least we hope they are logically related).  The user can only interact with 1 group at a time.  Essentially its a GUI that does "this", "that" or "something else."  Encapulating the functions This That and Something else in seperate sub vis aids scaleability, maintainability and readability since we have "This.vi", "That.vi" and "Something else.vi" rather than This That or Something else.vi.  If This breaks I can debug it while still being able to do something else or that.

[X.]

Sure, but if I need this and that in my main VI (or in both subVIs), it is easier to use tabs, IMO.

Note that it is just the typedef-inition that screws things up. Using a Tab the "intended" way works fine.

[Ben]

---

@X. wrote:

Sure, but if I need this and that in my main VI (or in both subVIs), it is easier to use tabs, IMO.

Note that it is just the typedef-inition that screws things up. Using a Tab the "intended" way works fine.

---

I think I tried to typ-def a tab control back in about LV 7.1. It acted wonky (like you described) and threw a monkey wrench into my plans. Since I did not (and still don't) know "what is the correct" functionality, I can not say it is a bug or not.

Sure is wonky and does not work as I expected.

Ben

[X.]

I linked the thread I quoted above back to this one, in the hope that NI will take a look at this issue/bug.

[JÞB]

---

@Ben wrote:

---

@X. wrote:

Sure, but if I need this and that in my main VI (or in both subVIs), it is easier to use tabs, IMO.

Note that it is just the typedef-inition that screws things up. Using a Tab the "intended" way works fine.

---

I think I tried to typ-def a tab control back in about LV 7.1. It acted wonky (like you described) and threw a monkey wrench into my plans. Since I did not (and still don't) know "what is the correct" functionality, I can not say it is a bug or not.

Sure is wonky and does not work as I expected.

Ben

---

Why not just ask how to best use your DAQmx Express vi in a Stacked Sequence Structure?  There are just plain better solutions.

I'll try to work up an example soon.  X, If you have some source that requires "This and That" that I could adapt I'd be pleased

[X.]

If it's been around since that long and Ben has already reported the issue, I guess it is one of these cases of wishful thinking I need to get a cure for (remember that the reason I was trying to typedef a tab was to be able to flip through them programmatically using an enum constant on my diagram, as also described by nrp in the other thread; in other words, the latter is really the functionality I am missing, not really that a typedef tab handles insertion - or deletion for that matter- of pages in its chilren nicely). Come to think about it, I agree that it would be unreasonable to expect a typedef tab to behave nicely in any way.

I am not sure that using subpanel would help in anyway with this functionality, since what I need is a quick way of having a list of the different GUI parts available as a enum constant on my diagram. Using different subVIs, I would have to create a typedef-ined enum, which I would have to manually update each time I had a VI, and would not be even sufficient for me to call that subVI (I would need the full path for each, and that would be much more than I need for legibility issues).

Finally, I would have to keep a copy of the different control values set by the user in different tabs and used in other tabs.

For quick-and-dirty GUIs as I am used to sketch out for one-of-a-kind projects, that's way too much overhead.

But as they say, to each his own.

[Ben]

Clarification:

I did NOT report it as a bug.

But as to the use...

Do you you really want to edit the tab control using only the Control Editor?

It just seems like a puzzle that is incomplete.

Ben

[X.]

I wrote "issue"!

In any case I have given up on typedef-ining tabs, in case that was not clear from my last post.

The workaround is to create a typedef enum that I edit each time I add (or remove/rename/etc) a page to the tab. It just needs to become second nature...