Tabbed Pages and FSMs

[sydney]

I use an FSM with a tabbed page display very frequently. The FSM, using its own strictly type def's enumerated constants, will navigate to the different tabbed pages by setting the tabbed pages value property: so any state of the FSM can tell the tabbed page display to present whatever page is desired to associate with the present FSM state. The tabbed pages cover most of the screen and do not have visible tabs making for a very useful technique to display large sets of data in my projects since there frequently is needed displays that show 30 - 60 parameter values on any one display page.

My problem is that the tabbed pages have an associated enumerated type for the page values, and I end up with a seperate strict type def enumerated type for the FSM. This works well but has major drawbacks: maintainability and scalability. I would like to change the enumerated type def for the FSM, apply those changes throughout the FSM (no problem at all!), and be able to apply those changes to the type def for the tabbed page display. Then I would like to add a tabbed page in the correct order or position to agree with the FSMs enumerated type.

So far I have experimented with trying to cast the enumerated types which can't be done because they are both strictly type def to different controls (I believe). And I have tried to take the enumerated type from the FSM and use it for the Tabbed Pages and vice versa also with no luck.

I also have tried to construct separate strict type defs, one for the FSM and the other for the Tabbed Pages and then edit both separately and then 'Apply Changes', but I have problems with the tabbed pages display as it seems that adding a page does not update the 'value' constants that I have previously used in the program, so I have to go back and delete and create anew all the previous 'value' constants for the tabbed pages, and that is a bookkeeping nightmare for a large program.

If I can overcome this limitation, this GUI code pattern would be an excellent development technique worthy of becoming a template! I can supply a simple example program, but it is so trivial I do not think it is necessary, but that might be because I use this technique so much. Any suggestions would be greatly appreciated.

Sydney

[ESST]

Hi,

I must admit that I am not sure if I understood question completely, however it sounds to me as though what you intend might need a script.

Intro

Add Pages to tab controls

Excample

Have a look, and even if its not what you need, you might find it interesting:)

[sydney]

Hi,

I must admit that I am not sure if I understood question completely, however it sounds to me as though what you intend might need a script.

Intro

Add Pages to tab controls

Excample

Have a look, and even if its not what you need, you might find it interesting:)

Make a simple FSM (finite state machine) with a while loop, imbedded case statement, and an enumerated type to handle the states. Now picture this code in the various states displaying controls and indicators on the various pages of a tabbed display. When the FSM state machine is in a particular state where it would be desirable to display a particular page that state's code would assign a constant, enumerated type to the tabbed page's value property to have the display automatically switch to that page of the display. All the needed pages were already there and the state machine is navigating to the various pages as needed, which is why I normally do not even show the tabs on the display as the user does not do any navigation, the FSM does. Typically I would have several pages for setting up the hardware, and several more to display the parameters from the hardware devices. Now this can rapidly get to the point where I have a couple dozen pages to manage along with the associated code to run the hardware. I need an enumerated type to manage the states of the FSM, and the tabbed page display needs it's own enumerated type to assign to the value property nodes when I want to change pages in the display. This last enumerated type is the main source of my problem since every time, while developing the code, when I need to add a page I then have to go back to every property node and delete the old constant and install a new enumerated type!

I made a simple example to illustrate... Sydney

tabbed_pages.vi

tabbed_pages_enums.ctl

tabbed_pages_enums_2.ctl

[ESST]

Hi,

Seems I missed the mark completely. Thanks for the thorough explanation and examples.

Have you tried using a "To unsigned word Integer" primitive after the case typedef, before the Tabbed control value property? The value should accept an integer, and as long as you keep the number and order the same, you should get away with one typedef.

[Daklu]

Sydney,

I opened up your example and the first thing I read was, "Trying to figure out how to use the same type def'd enums for an FSM state enum and the tabbed pages enum." I don't think you want to do this even if you can figure out how to. It will needlessly couple your user interface to the underlying code and introduce a lot of complexity.

I would address this issue in two ways. First, I would create a translator vi that accepts the FSM state as an input and outputs the tab that should be shown when in that state. This keeps all your state->tab code in one place and makes it easier to change in the future. Second, create a typedef from an empty tab control and use that typedef in your translator vi. When you add a page to the typedef all the constants inside the translator vi are automatically updated.

Note the tab typedef is simply to provide a way to automatically update the constants inside the translator vi. You can't put controls on a tab inside a typedef so the UI tab control is different from the typedeffed tab control. You do have to be careful to keep your page names on the UI tab consistent with the page names on the typedeffed tab, otherwise LV can't coerce from one to the other.

HTH

Dave

Sydney 8.6.zip

[sydney]

Sydney,

I opened up your example and the first thing I read was, "Trying to figure out how to use the same type def'd enums for an FSM state enum and the tabbed pages enum." I don't think you want to do this even if you can figure out how to. It will needlessly couple your user interface to the underlying code and introduce a lot of complexity.

I would address this issue in two ways. First, I would create a translator vi that accepts the FSM state as an input and outputs the tab that should be shown when in that state. This keeps all your state->tab code in one place and makes it easier to change in the future. Second, create a typedef from an empty tab control and use that typedef in your translator vi. When you add a page to the typedef all the constants inside the translator vi are automatically updated.

Note the tab typedef is simply to provide a way to automatically update the constants inside the translator vi. You can't put controls on a tab inside a typedef so the UI tab control is different from the typedeffed tab control. You do have to be careful to keep your page names on the UI tab consistent with the page names on the typedeffed tab, otherwise LV can't coerce from one to the other.

HTH

Dave

Sydney 8.6.zip

THANKS FOR THE SUGGESTION!