Hello Varun Kumar,
You can access an autoobject and invoke its methods from the native (backend) code. Please see the section: Invoke GUI application code from device. Concrete: in the class of the autoobject please implement methods to query the variables. Then from the native code you can invoke these methods and so obtain the respective values. Directly accessing variables existing within autoobject is also possible, but not the recommended nor documented approach. Anyway, if you are experienced with Embedded Wizard you can analyze in the generated code how autobject variables are accessed and copy this code to your backend implementation. Be aware if you are using strings or multi-threading as explained in the section Integrating with the device.
The other way, accessing native (backend) variables from Chora code is also possible. Use the native statement for this purpose. Assuming you have some backend integer variable named Voltage and you want the value of the variable to be accessed in GUI:
// Chora local variable corresponding to the type of the backend variable.
var int32 v = 0;
// Following code section is used in the target system only
native ( v )
/* Extern declaration of the variable to allow the C compiler
to compile and linker to link with the variable. */
extern int Voltage;
/* Copy the content of the global variable to the local vaiable */
v = Voltage;
// Now you can evaluate the local variable 'v'. It contains the copy of
// the variable 'Voltage'.
In fact, the best approach depends on the function the variables will have in the application. I would distinguish between:
Case 1: The variables are modified by the non-GUI device code only. For example, the variable stores the actual voltage measured in the device. The GUI evaluates the variable to display the voltage only. In such case store the variable in the backend device. GUI uses native statement to read the variable content.
Case 2: The variables are modified by the GUI code only. For example, you have a GUI intended to control multiple engines. Which engine is actually displayed is controlled by a variable the user modifies in the GUI. Changing this selection changes the variable. All GUI components use this variable to obtain information which engine is actually the selected one. Accordingly the GUI displays the state of the selected engine. The variable itself is not modified in the backend code. It is not necessary to store the variable in the backend.
Case 3: This is an enhanced case 2. The variable is used by the GUI only. It is however important to save the latest state of the variable so that after switching-off/on the device the variable is automatically restored. In this case the modification of the variable has to be stred in the backend too. The GUI itself does not need to read the backend variable each time it is evaluated. It uses its own variable as described in Case 2 above. The backend version of the variable is only evaluated when the device is switched-on to get the initial value for the GUI variable. After changing the variable in the GUI the corresponding backend value has to be adapted accordingly
An additional hint: for the above draft application cases Embeded Wizard provides the concept of a Device Property. This property caches a value existing in the backend. The backend code can update the property if the value stored in the backend variable changes. On the other hand, GUI code can modify the property and so trigger an action in the backend code.
Also please see section Implement the Device Interface. In the following subsections it provides an overview of various application cases and the recommentations how to implement them.
Does it help you?