In my previous post How to change a tab strip selection, I discussed the use of HyperLinkSys as a means of passing data from a nested view screen to its parent screen. In that technique, the data passed from the nested view was used to change the selection of a tab strip on the parent screen. In keeping with the theme of initiating an action from a nested view, I will present a different technique using custom events for more complex interactions.
If you have scripted in Studio you have seen and worked with events. And after working with events inside of Studio, you quickly discover that your ability to impact when those events fire is limited. If you’re like me you have had you fill of trying to use EventRestarted to do some clever things. Or in my case, not so clever things. Fortunately, there’s another tool that we can use: the workspace.
You may be familiar with the workspace feature in Studio that provides the ability to save open screens and their locations. But did you know there is a scripted component to workspaces? The workspace has some interesting methods that we can use to orchestrate some creative screen interactions. The CygNet Help file has some information on those methods so I won’t get into that here but I will share an example that may illustrate their usefulness.
Let’s look at an example. Here I have a main screen that has a tab strip and a nested view. The tab strip controls the file path of the nested view. When each tab is selected, a different screen is shown in the nested view.
Standard boilerplate stuff, right? But say I want the screens in Tab 2 and Tab 3 to do other stuff when the buttons are selected on the screen in Tab 1 but not when Tab 2 and Tab 3 are selected directly.
Here, I am controlling the text of a text tool on Screen 2 when the “Jump to Tab 2” button is selected. In order for this to happen, the “Jump to Tab 2” button uses the HyperLinkSys method to pass some information to the Main Screen. There the Main Screen is then able to control the tab strip selection. After it does that, it will raise a custom event using the RaiseCustomEvent workspace method. This is one of two methods in the workspace to raise a custom event. This particular method accepts three parameters, and similar to HyperLinkSys, the contents of those parameters (at least the first two) is up to you to decide. The third parameter is typically the view id of the screen. We’re not concerned with the view id for now so I’m not going to address it here.
On TheFrame/TheView properties of a screen, there is an event called EventCustom. This event is what listens to any custom event raised. And the script in that event determines what, if anything, is done when it hears a custom event. In this example, Screen 2 and Screen 3 have script in this event to take the data passed in the custom event and sets a text tool’s text property.
Now this is all done within the borders of a single screen, the Main Screen. And as such, there are other techniques to achieve the same result. But what if Screen 2 wasn’t a nested view of the Main Screen and it stands alone, like this:
Now, let’s click the “Jump to Tab 2” button. Here is the result.
This interaction is a bit tougher to achieve without a custom event. You see, Screen 2 still changed the text on the text tool when the screen is opened outside of the nested view. This is because custom events can be heard and reacted to by any open screen in the same instance of Studio. I’m attaching the screens referenced in this post below.
You will recall I said there are two methods to raise a custom event. The other method is called RaiseGroupCustomEvent. This method can be used to raise a custom event to a group of screens. Sadly, my time is up for today so I’ll have to leave this for another day. In the meantime, have fun throwing some custom events…be different and take lots of pictures.