Variables and parameters are identifiers. See Identifiers, Variables, State Variables, Parameters. This means they are available to UJML code according to the scoping rules. See Scope. It also means they may be shared between modules. See Sharing.

Because parameters may only be declared in the context of a function, parameters are always scoped locally to the function and are not available outside of it. See User Defined Functions. Parameters may not be shared.

Variables (both standard and state variables) are scoped to the context where they are declared. See Scope. If a variable is declared in a function, transition, or event handler it is locally-scoped to that function, transition, or event handler. If a variable is declared in a module, it has module-level scope. If a variable is declared in a state machine it is scoped to that state machine and any child state machines it contains.

Variables (both standard and state variables) contained by state machines may be declared as public or private using the visibility modifier. See Sharing. Public variables of a state machine may be used by UJML code which has the state machine it its scope using 'dot notation'. See Identifiers. 

Public state variables of a state machine are often used to signal to code outside the state machine that it has changed in a significant way. See State Machines, State Variables. This is done by creating an event handler for the public state variable, using 'dot notation', in a context which has the state machine in its current scope.

Module-level scoped variables (both standard and state variables) may be shared by declaring them as exported or imported using the access modifier. See Sharing. This works by exporting them from a parent module and importing them into a child module which the parent has linked to. See Linking Files. 

A shared variable is one data value with identifiers in the module it was exported and in every module it is imported to. If a child module attempts to import a variable which is not exported by its parent, or by the parent's parent (and so on), the identifier is still valid; it just refers to a local data value instead.

The following example declares three public state variables which are activated when the user clicks the up or down buttons. It is part of the scrollbar.ujms sample.

<state-var name="sScrollUp" type="boolean" visibility="public"/>
<state-var name="sScrollDown" type="boolean" visibility="public"/>

The following example shows how to provide state transitions with scripting for each of the above state variables. It is part of the scrolltextbox.ujms sample.

<state var="VerticalScrollBar.sScrollUp">
    <transition value="true">
        <script>moveText(1);</script>
    </transition>
</state>
<state var="VerticalScrollBar.sScrollDown">
    <transition value="true">
        <script>moveText(-1);</script>
    </transition>
</state>

The following example shows how to export some variables from an application file. It is part of the visualelements.ujml sample.

<var name="mSingleLineText" type="string" access="export"/>
<var name="mDefaultLabelText" type="string" access="export"/>
<var name="mMultiLineText" type="string" access="export"/>
<var name="mDefaultMultiLabelText" type="string" access="export"/>

The following example shows how to import to a linked partition file the variables exported above. It is part of the velocale.ujml sample.

<var name="mSingleLineText" type="string" access="import"/>
<var name="mDefaultLabelText" type="string" access="import"/>
<var name="mMultiLineText" type="string" access="import"/>
<var name="mDefaultMultiLabelText" type="string" access="import"/>

Identifiers, Scope, Sharing, Variables, State Variables, Parameters, User Defined Functions, scrollbar.ujms, scrolltextbox.ujms, visualelements.ujml, velocale.ujml