LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to create a tab control and enum type defs?

I see how to get LabView to make a typedef from a tab control, but I can't seem to find a way to do the reverse, create a tab control from an existing enum type def.  Seems like if a person needs already has an enum, the he ought to be able to make tab control from that.

 

0 Kudos
Message 1 of 7
(4,629 Views)

To me, it does not make any sense what you write. You can have Enum type or TAB type control/indicator. Do not mix these two. These are different things!

 

The fact that you can save any of the above objects as Type Defined control, is another thing...  

 

Message 2 of 7
(4,598 Views)

They are not exactly the same type. The enum is a type GObject >> Control >> Numeric >> NamedNumeric >> Enum

The Tab Control is a type GObject >> Control >> PageSelector >> TabControl. 

 

Even though they can both be represented as integers.

 

You should not have to make tab controls very often though, maybe once per application. You could probably write a scripting function that does populates a tab control with pages corresponding to the items of an enum.

Message 3 of 7
(4,590 Views)

The closest that I can get to what you want (Labview 2012) is to open the typedef, right click the enum control and replace it with a tab control.  This removes the enum values and requires you to manually re-enter them but hopefully you don't have many values.  I don't understand the need for this and it doesn't make sense to me why you want an enum with a tab control as its front panel object but it "should" work.  It may be a tedious task but at least your existing references to the typedef will be in place and updated.  Be sure and save your work before attempting it. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 4 of 7
(4,588 Views)

create a tab control from an existing enum type def

 

I am still not sure what you want, but if you just want to change TAB page captions during runtime, based on an Enum element list, do the following:

 

ewnumTAB.png

Message 5 of 7
(4,574 Views)

Thanks All. I think gregoryj came the closed to answering the question that I was getting at. Also,   is close, but I'm just trying to keep the enums and the tabs synced during development.

 

Here's what happened.  I'm working on an existing VI that has a number of local variables created from a single tab control so that the tab focus could be changed programmatically throughout the VI.  I added a new tab and unwittingly broke all the places the tabs were selected.  In each place I think the author right clicked and created constant inputs to each of the local variables.  When I added the tab, the constants didn't have all of the enum states.  It would be nice if adding a tab didn't break all the places that it was set.

 

The solution was to go back and create a type def from the existing tab control and then recreate all of the constant inputs to all of associated local variables.  Then I added the new tab to the tab control type def, and all the constants were updated accordingly.  Nothing broke when I added the new tab this time.  I think I have my solution, but it brings up an academic question.

 

Enums can be type def'ed.  Controls and indicators can inherit the states of type def'd enums.  From controls and indicators, a person can right click and make constant enums also picking up the states of the enum.  When case statements wired enums (controls or constants), they pick up the states of the enums.  In object oriented terms, controls, indicators, and constants objects can all inherit the states (and changes to those states) of an enum, and case structures can inherit the states of an enum when wired.  Why can't tab controls inherit the states of the enum?

 

Its like enums should be lower level objects, lower level object properties, or even lower level data types.  Its like its a data type on top of a data type.  Its an integer, but its an enum of type integer.  It would be nice if constants, controls, tab controls, case structures, and the like could all be able to pick up the states (and updates to those states) of enums during development.  I think in C code an enum is a data type.  You can type def an enum, and then you can typedef any variable from that typedef, and the states of all the variable always stay synced.

 

Does anybody with more clarity on the subject understand what I am asking?

0 Kudos
Message 6 of 7
(4,566 Views)

Ok, I see your problem 🙂

First of all lets clarify the wording. When you create a local variable for a TAB control, and make a constant input for this constant, it is NOT going to be an Enum! This constant (however you create it from that TAB control), is going to be a "TAB constant", for that TAB control. So ok, we can use this to change which page is visible for that TAB control. And yes, it is a good practice to make the TAB control Typedef, because then whenever it changes, the changes should propagate through all its instances (constants, etc).

 

Enums can be type def'ed.  Controls and indicators can inherit the states of type def'd enums.  From controls and indicators, a person can right click and make constant enums also picking up the states of the enum.  When case statements wired enums (controls or constants), they pick up the states of the enums.  In object oriented terms, controls, indicators, and constants objects can all inherit the states (and changes to those states) of an enum, and case structures can inherit the states of an enum when wired.  Why can't tab controls inherit the states of the enum?

 

Why would other controls inherit states of this Enum control? One previous poster showed you the class hierarchy of Enum and Tab controls:

The enum is a type           GObject >> Control >> Numeric >>          NamedNumeric >> Enum

The Tab Control is a type GObject >> Control >> PageSelector >> TabControl. 

0 Kudos
Message 7 of 7
(4,541 Views)