All ViewModels have predefined variables that help you interact with the ViewModels and their data. Depending on what you're using your ViewModel for, you use different variables and different variables are available.
The most commonly used are vCurrent and vSelected and selfVM. Use vCurrent and vSelected when you have a cursored ViewModel. (Please read more about cursored and uncursored viewmodels in a separate article.) You can turn off the vCurrent and vSelected variables by setting a tagged value that you can read about here.
See also: Built in ViewModel variables
vCurrent and vSelected allow you to see at runtime which item in a list has been clicked upon by the user. Or in the case of if it is turned on, they can select multiple items in a list - then those objects that have been selected will be available in the collection called vSelected_ and the name of the ViewModel class. In this example, we will have one vCurrent that is not going to change because this is a rooted ViewModel and vCurrent_ViewOneThing points to one thing object - it will be the same as self.
Remember that the vCurrent points to the ViewModel class object that is active regardless of which ViewModel you are referencing that variable. In contrast, "self" is dependent on where the expression is placed. If it is an expression in, for example, the blue detail ViewModel class in this example:
it will be a detail object. Because this is an expression here, the action column on the root green ViewModel class "self" references the root of the whole view.
If view model actions are made, they very often use vCurrent or vSelected of the list of things or the specific object that action should act upon.
You also have selfVM. selfVM references the running ViewModel itself and is used within action language expressions to execute things or find out the state of the view itself, for example, to execute an action, to execute something in persistent storage that is SQL, to execute the query plan again to find out which objects have been changed in the view and to examine or execute things related to access groups or security.
You can also define your own variables for any use that you want, for example, to keep a reference to an object that the user is working on. Also, note that if you don't use placing hints, if you don't have a user interface that you use this view model for an API or a report, the available variables change. For example, variables that are not for vCurrent and vSelected are not used in reporting. Moreover, in an API scenario, vCurrent and vSelected are sometimes used in special circumstances to process the JSON or XML being imported but most of the time, they are not used.
There are also variables defined in specific action cases - for example, if you have a model dialog that is an action that opens another view, and then to access its result, you get specially named variables that are available in the action that executes after the model has been closed.
You can always see which variables are available by, for example, opening the OCL editor for an attribute or as in this example, the Action Editor for an in-view action and then exploring in the Action Editor which methods and variables are available on the right-hand side as in this example.
Editing and setting initial values
Snapshot of editing ViewModel variables. The arrows point to invalid initialization.
The KundId variable has an initial value that is an expression. Initial values can't be an expression. Unfortunately, the model checking isn't looking at this, so no warning is given.
1-1-1 or #1-1-1 are valid dates, so those are also invalid.
Initialize variable in an init-action that runs once. i.e. a periodic action that only runs once, or initialize in using the OnShow expression of the action that navigates to the view.