Design States are a visual representation of screen which is in a different state, because data has changed. A Design State may represent a screen after running an animation or a set of data changes. Design States allow users to communicate how a screen might change during the normal execution of your application.
In the screenshot below, we have the default Screen on the left and the Design State on the right. This Design State represents what the screen will look like if the user selects the fan toggle button.
Design States enable the user to work with content that may not be visible by default. In the example below, the Design State 5DayState has a single argument which is the show_5_day animation, this is a representation of how the screen will look when a user presses the "5 DAY FORECAST" button.
Model elements cannot be added/removed from Design States, these operations are always global. Removing a control, will remove the control from the application. Design States are limited to making changes that can also be made at runtime, this means setting internal model object attributes (x, y, width, height, hidden) and changing Storyboard variables.
There are several ways to create new Design States.
-
> >
-
Keyboard shortcut CTRL+N+D (Windows/Linux), COMMAND+N+D (Mac)
-
When we right-click on an existing Design State and choose > > , you will be given the option to create a Design State from the current Design State, this is effectively going to copy the current Design State.
Learn how to edit a design state in Storyboard Designer.
Once a Design State is added to the application, a new button will appear at the bottom of the . This is the Master/State context selector. This button is responsible for determining what information is shown in the and , as well as how changes will be applied to the model.
This button also shows up in the Storyboard workbench toolbar.
Master Context and State Context can be thought of as Global and Local contexts.
-
When in Master Context, changes made in the Storyboard Editor, Properties View or Variables View will affect the global state, the regular Screen and all Design States that do not specifically override a value will inherit the change.
-
When in State Context, changes made in the Storyboard Editor, Properties View or Variables View will affect only the currently selected Design State. The exception to this is changes made to elements on the regular Screen will still be propagated to all Design States that do not specifically override the value, since changes to the regular Screen will always be global.
Changes made to model objects in a Design State will automatically add the changes to the Design State. Changes to internal model object attributes such as x, y, width, height and hidden can be made directly through drag and drop operations as is typical when working with the Storyboard editor. The primary difference with the introduction of Design States is depening on your current Context Mode the changes will either be applied globally or locally.
Keep in mind that additions and deletions are always global operations.
When in State Context the title at the top of the Properties View will be green and marked with a Design State icon. All properties that are changed in a Design State will be highlighted green and styled in bold text.
When in State Context, changing a property that does not have a variable bound to it will open the following dialog:
The purpose for this dialog is that Design States can only change properties that can be changed at runtime, in the case of render extensions, only properties with variables bound may be changed at runtime.
-
If the change is intended to be a global change, then the user will select .
-
If the user actually wants to remain in State Context and change the specific Design State, then creating a new variable will allow changes to be made specifically to the selected model object in the context of the current Design State.
When we select a Design State from the Application View or from the Storyboard editor, the Properties View will be populated with the Design State and it's arguments.
A Design State can be made up of several arguments, any number of which may be animation arguments. Just like animations at runtime, Design State animation arguments can specify a context in which to run. To specify a context, choose the button of an animation argument and select , animation keys which are context specific (i.e. ${control:.. or ${layer:..) will be resolved with the specified context.
Variable changes are simple key-value assignments. The most appropriate editor for the specified variable will be shown in the properties view such as an RGB editor for color variables or an image selector for image variables. At this time, context based keys are not supported so all keys must be fully qualified paths to variables.
There are several ways to remove a change from a Design State.
-
With a Design State selected, in the Properties View, click the menu button
beside one of the Design State arguments and select
or .
-
From the Properties View in State Context, right-click on a Design State icon on a Design State property (bold label, highlighted in green) and select .
-
For internal variables:
-
For user variables:
-
-
From the Variables View in State Context, right-click on a Design State variable (bold label) and select .
When removing a variable from a Design State, the following dialog will appear, listing all the arguments that will be removed from the Design State.
When not actively working with Design States, they can all be hidden instantly. Toggling will override the visibility of Design States so that none are visible. Toggling will restore them to their previous visibility, those Design States that were individually hidden will remain hidden.
Individual Design States can be hidden/shown in the Application Model View. You may want to hide all the Design States that are not related to the current task you are working on. Visible Design States will have an effect on the performance of the GDE Editor. By hiding Design States, the has less drawing to do, so it will be inherently quicker.
Design States can be converted into either an animation or into a named data change. To convert a Design State, right click on a Design State in the Application Model View, under there are three options:
-
an animation will be created with all steps having a duration of 500 ms for numeric data or 0ms in the case of strings or booleans.
-
a named data change will be created. Animations are 'flattened' such that only the final values will be included in the data change.
-
when converting a Design State into a Design State, all animations arguments will be 'flattened' and included in the new Design State as a series of variable change arguments.
One useful feature of Design States is the ability to create a custom starting point for the Animation Preview tool. Some animations have a forward and a reverse animation. With Design States, the Animation Preview tool can be instructed to begin the preview from a particular Design State as the starting point. In order to specify which context to use for the Animation Preview, there is a field, shown below.
Opening the Design Context dropdown and selecting will open the following dialog, which is used to select the specific context in which to run the animation. The selected model object may be in a Design State, or may be the Design State itself.
The current animation is hide_mon_to_fri which is the reversed animation of show_5_day. In this sample, we have a Design State that represents the show_5_day animation, 5DayState, by selecting it as the starting point for the Animation Preview, we can preview hide_mon_to_fri starting from the end of the show_5_day animation.