[Answers] UI State

[josipradnik]

The UI State is being set in the Click event of the buttons. Switch back to the Development View and open up the Field Attributes for the 'Show Orders' button (double click on the border of the button). Here you will see the inline delegate to change the state to 'state1'.?changestate:state1



If you do the same for the 'Hide Orders' button, you will see that clicking the button changes the state to 'state2'.
?changestate:state2



The UI States are defined in the UI States Editor and written to a table called <app-name>_uistates - here example_uistates_uistates. When you first open the UI States Editor, you will be prompted to allow the table to be created if it does not already exist.



Here's the UI States Editor with the states 'state1' and 'state2'. The 'state2' UI State is selected here and has one row of 'property-name=value' entries (in the bottom section) for when the UI State is active (true) and not active (false). A UI State can have multiple rows or entries. So, when 'state2' is active, affected UI components will have their 'visible' property set to 0 (false) and when 'state2' is not active (i.e. the default state), affected UI components will have their 'visible' property set to 1 (true). Make sure you set the default state in this way so that when you are in Development View, which uses the default state, you can see and manipulate all your UI components.



Here's 'state1' - remember this is the UI state activated when the 'Show Orders' button is clicked, so it makes affected UI components visible when it is active, and also when the default state is active.



Finally, how does the 'Orders' grid become an 'affected UI component'? Double-click on the 'Orders' grid section header (or click the cog) and scroll down to the 'UI Presentation Rules'. The 'UI States' attribute has a comma-separated list of UI States that affect this section. In this case both 'state1' and 'state2' are listed, so the visible property of the section is set by the changes of state.



'Initial UI state' for the App (also available at Page, Section and Field/Gadget level) is set to 'state2'.



Initial UI state attribute has been added (v1.1.3

---

Q:
what the effect of multiple UIStates
A:
The attribute is set when the state is changed. So if you have state1 that sets visible=1 and state2 that sets visible=0 and issue:

?changestate:state1||changestate:state2

visible=0 for the relevant controls because state2 is the last state to be set.

If you issue

?changestate:state2||changestate:state1

visible=1 for the controls, because state1 is the last state set.

---

First thing to bear in mind, is that the UI Presentation Rules apply at Runtime, so toggle into Runtime View when you want to see the effect of these.
UI States are demonstrated in the example_uistates App (in the Lianja App Builder distribution). The Orders grid has the UI States 'state1' and 'state2' set in the UI Presentation Rules. States can be defined using the UI States Editor to set up property values when a particular state is active. There is more information about UI States here and here and complete documentation to come.
Visible when takes a condition. When the condition evaluates to .F. (false) the object will not be visible. Note: for sections this is only currently available for Form and Grid standard Sections.

---

Any UI States will fire and set the False value in Development View - so you will see that firing as you move between Runtime and Development and when you first open the App.

---

The || pipes are for chaining together inline delegates or applying multiple operations in one Lianja.showDocument() call.
As you can see, you can change to multiple states with one changestate: action.

---

The UI states in the attributes (page, section,field, or gadget) is a comma separated list of names.
Any time a change of state occurs it is applied to those UI elements that have that state name in their comma separated list.
what this means (by design) is that a UI element e.g. a field, can be in multiple states and depending on the properties specified look and behave differently.
This UI state machine is built into the Lianja ART (Actions Rules and Transitions) engine to reduce the amount of coding required.
By setting up the UI states using the UI States Editor, you can change how your App looks like and behaves like without having to make any code changes.
Also worth mentioning is the "Visible When" and "Enabled When" in the attributes which automatically hide and show UI elements based on a condition as the user is navigating and/or editing data.

---

Q:
Getting on really well with UI states now - makes screen control really easy.
Quick question - let's say we have 3 UIStates which affect a particular field. Each one is set up as :
Some condition = .T. => visible=1
Some condition = .F. => visible=0
Are we right in thinking that :
if ALL UIStates are visible=1 - field WILL display
if ANY of the UIStates are visible=0 - field will NOT display
Seems logical & appears to be the behaviour we are seeing but just wanted to be clear.
A:
UI States are cumulative.
So for example if you have applied a UI state that changes the background color and another that makes it visible, then both states are active,
So applying a state with visible=0 will indeed operate as you would expect.
However when you change the UI state so that visible=1 the background color remains.
This is why there is a "true" set of attributes and a "false" set of attributes.

---

---

​All topics in [Answers] alphabetically:http://www.lianja.com/community/show...ll=1#post12352

[josipradnik]

Lianja States provide you with a powerful mechanism for handling complex business processes using a "State machine" which is built into Lianja.
State machines have many interesting uses. States can easily describe user interfaces but they can also be used to model high-level business processes and many other things.
In a Lianja App, each UI element (App, Pages, Sections and FormItems) contains a (optional) comma separated list of "States" that the UI element responds to. In Lianja 3.2 we have added a new delegate called stateChanged(cState) which is called whenever a UI State is changed. This provides you with a programmable hook for managing App state.
e.g:

Lianja.showDocument("changestate:namelist")

or

Lianja.showDocument("page: page1?action=changestate&state=namelist")

or

Lianja.showDocument("section:section1?action=chang estate&state=namelist")

The delegate is called with one argument, the name of the state. Note that the namelist is a comma separated list so you can trigger multiple UI state changes at once.
When a "resetstate:namelist" is applied to the App the delegate is called with a single argument which is preceeded by a "-" sign e.g. "-editing".
Note that changing UI state is only handled in runtime mode not the development view.

---

---

All topics in [Answers] alphabetically: https://www.lianja.com/community/sho...ll=1#post13748

These answers are also systematized on the site "Lianja developer": https://lianjadeveloper.wordpress.co...gory/ui-state/