How to change a tab strip selection

June 18, 2015 / 0 comments / in Applied Engineering  Studio Tips  / by Blake Miller

Well as a similar joke goes, first the tab strip has to want to change.

Tabs are commonly used in screen navigation. They do a good job of helping us organize our screens and they don’t require a lot of screen real estate. I used them extensively when building CygNet for Production. So much so that Applied Engineering built an entire management system to control the configuration of the tabs, but that’s a story for another day.

In working with tabs, I’ve run across a challenge. I want to be able to change the tab that is selected. The simple answer is to have the user select the desired tab and that’s it, right? Well, that would make for a pretty short and boring post. So let’s spice it up a bit.

Here is how I have my screens setup. It’s a typical screen layout that includes a tab strip and a nested view. The tab strip drives what screen we are going to pass into the nested view. This simple approach works very well for when the user is doing all the tab clicking. However, there are times when I want a screen in the nested view to change the tab strip in the parent view to a different tab selection and therefore show something else in the nested view.

I’m going to parse away everything but the task at hand…changing the tab selection on the parent screen from a nested view screen. In order to do this, the nested view screen needs to be able to tell the parent screen to do something with the tab strip. One way we can do this is via a HyperLink, or more specifically, its brother HyperLinkSys.

I’m getting ahead of myself. Let’s first look at the components of the screen.

Here we have one screen with tab strip that has four tabs on it.  Below it is a nested view tool that is showing a screen that has four buttons on it.  Below is what this screen looks like in design mode.

In this example, when we select one of the buttons in the nested view the appropriate tab in the parent view will be selected. I realize this example may be overly simple but I’m hopeful it will illustrate the point.

A minor detail is that in order to script this we will need to know the individual tab key names of the tabstrip control. In this example, I just chose something easy (TAB1, TAB2, etc…).

Now, the fun begins. I’m sure you are familiar with the HyperLink method as they are used quite frequently to link to other screens. This is done with buttons, script, you name it. We know that things like file path, site.service, facility id, and if the screen should close or not are parameters of a HyperLink. Now, you can quickly see that there isn’t really anything in these parameters that will allow us to specify our desired tab selection. Sure an enterprising individual could probably make this work but it’s not optimal and could create administrative confusion in the long run. So, there has to be a better way.

HyperLinkSys will now be making an appearance. It has only one parameter, SysParms. What are SysParms you may ask? Well I don’t know either but what I do know is that is just a string. It’s whatever you want to make of it really. It can be delimited text, XML, the word “hi”, etc…

If you look at the sample nested screen, you will see that the four buttons each will have a similar line of script. Something like:

theview.HyperLinkSys “TAB:TAB1”

I am using a simple delimited string to specify the action I want to take, “TAB”, and the tab I want to select, “TAB1”.  When you are in the nested screen itself, you can click those buttons all you want and nothing will really happen, short of a sore finger.  This is because, nothing is reacting (or listening) to this call.  As you can imagine, there should be some code somewhere that will “hear” this request, parse the string, and perform the action.

Let’s go over to the parent screen, the one with the nested view. You will notice that there is an event called EventHyperLinkSys on the Nested View Tool. When those buttons on the nested view screen calls a HyperLinkSys method, the Nested View Tool’s EventHyperLinkSys is what “hears” it. Which is good, because we need the parent screen to actually change the tab selection.

Below are screen shots of the event on the nested view tool and the code behind the event.

The above script can be copied from the supplied screens.

You can see here that the code is doing some minor input validation of the SysParms passed in by looking for a semicolon.  Once we get past that, it parses the string into two parameters by splitting on the semicolon.  At this point, we have an action and the data of the action.  Again, I could have simply used TAB1, TAB2, etc…here but I wanted to add a bit more flair.  It also illustrates the point that you may want the parent screen to take different actions from other nested view screens and you need to account for that.  Once we know the action to take and the desired tab selection, we finally tell the tab strip to change its selection.

I realize that this is a simple example and much more could be done.  For example, what if when I change the tab selection on the parent screen, the nested view opens up a different screen.  And that screen has a tab strip on it too that I want to change with the same action?  I do this in CygNet for Production where I have an overview grid on the “Dashboard” tab and the rows have a double-click event.  On that event, I change the main tab strip navigation selection from “Dashboard” to “Well”.  And then on that Well screen, I change its tab strip selection from “Overview” to “Detail”.  Check back in a few weeks and we’ll talk about that.

Below are the two screens I referenced in this post. Simply unzip the file and place them anywhere on your computer. These screens were built using CygNet Studio version 8.1.3.

Tabstrip Selection Screens