Prime app variables

[Jonathan Cameron]

Could someone point me to information on how app variables work in customized Apps?

Here are some of the questions I have:

1. When you create a customized Solver App called MyApp, and you set the equations in the App code, when does that definitition get set? I tried this and I could edit the equation but I was not sure when the predefined value took effect. I tried doing "Start" for the app and the edited value remains. For instance:

Code:


   Export MyApp()
   BEGIN
      MyApp.Eq='x^2+y^2=1';
   END

2. How do I define and use app-specific variables? For instance, if I define like this:

Code:


   Export v1;
   Export MyApp()
   BEGIN
      MyApp.Eq='x^2+y^2=1';
   END

Here is what I understand:

1. When MyApp is active, I can access v1 by using 'v1'
2. When MyApp is not active, I can access it by MyApp.v1
   

What is confusing me is that when I look at [Mem] and look at user variables, I see entries for all the variables I defined (with EXPORT) in MyApp--but without any MyApp prefix (even when I have another app active)--and it does not offer an option to delete it. Why doesn't it indicate what App it is associated with? When I edit it, it does have the value set my MyApp, so I'm sure it is for that app. When I define the same variable in two different Apps, I see the same name twice in my "User Variables" list under [Mem] -- without any obvious way to distinguish them (other than Edit-ing).

The act of putting togther this post has helped me understand this better, but I would still welcome any suggestions on best practices/advice, examples, and documentatoin.

Thanks

-Jonathan

[Han]

Your understanding of how app variables work is just fine. The only notes I can add are:

1. The prefix MyApp is not necessary within the source code of the app. In fact, you generally only need use it when outside of the scope of the app. It is very much like a C/C++ class in which one does not need to explicitly have the class prefix when referring to objects within that class.
2. Don't EXPORT variables which you do not intend to be visible to the user. It may be the case that you want manual access to all the variables, so this can be ignored. But if you don't need to know the values outside of the solver app, then leave them "hidden" by removing the EXPORT directive. This will make the memory browser less cluttered with seemingly duplicate variables. Some, however, you have no control over (such as built-in variables that are inherited in a custom app) though these do not appear in the memory browser.
3. Hidden variables still take up memory -- you will see it as part of the size of the custom app.
   

The memory browser is currently very basic in form. Your observations are correct -- there is currently no way to distinguish vars in one app from vars from another app if they happen to have the same name.

[Jonathan Cameron]

(12-13-2013 04:02 PM)Han Wrote:  2. Don't EXPORT variables which you do not intend to be visible to the user. It may be the case that you want manual access to all the variables, so this can be ignored. But if you don't need to know the values outside of the solver app, then leave them "hidden" by removing the EXPORT directive. This will make the memory browser less cluttered with seemingly duplicate variables. Some, however, you have no control over (such as built-in variables that are inherited in a custom app) though these do not appear in the memory browser.

Thanks Han,

Regarding your point 2: Do you mean that I declare the non-exported variables with a LOCAL statement within the main BEGIN-END block for the App or something else?

-Jonatha

[Han]

(12-13-2013 05:27 PM)Jonathan Cameron Wrote:  Thanks Han,

Regarding your point 2: Do you mean that I declare the non-exported variables with a LOCAL statement within the main BEGIN-END block for the App or something else?

-Jonatha

No, local variables are entirely different as their scope is limited to the (sub)program that delcares them. When you use EXPORT, you are essentially creating a global name (either a variable or a program) that becomes visible to the user. They can interact with it. These global variables are likewise accessible by any other program (be it within the app, or even from outside the app provided the calling program uses the proper app prefix). If you want to create a variable that is likewise accessible to programs, but NOT to users, then you simply remove the export command. So for example, the source to your app may have:

Code:


EXPORT myvar1; // global var which users can alter; other programs can use
myvar2; // global var which other programs can access, but is hidden from users

EXPORT Program1(a,b,c) // this program is visible to users and other programs
BEGIN
  myvar1:=a+b+c;
  myvar2:=a^2+b^2+c^2;
END;

Program2(x,y) // this program can be used by Program1 but not by users
BEGIN
  LOCAL r, s, t; // these variables can only be used within Program2
  myvar1:=a-b*c;
  myvar2:=r-t+x*y;
END;

So in the snippet above, the local variables are a, b, c, x, y, r, s, and t and can only be accessed by their respective programs. The global variables myvar1 and myvar2 can be used by any program; however only myvar1 can be altered by users manually. For example, a user could simply type: myvar1:=9; to override the current value, whereas they cannot alter myvar2 whatsoever.

[Jonathan Cameron]

Thanks Han,

That was very helpful and I feel that helps answer several questions I had.

A couple more questions along these lines: Suppose you have a Solver-derived App and you set the equation by setting the value of E1 in the App code. Part 1: What is the correct syntax? Part 2: Suppose I edit the equation in the App [Symb] view. How can I restore the correct version of the equation as set in the App code? is there some way to "reset" an app back to original values? Or do i need a function for the App (via Menu perhaps) that resets all the equations?

-Jonathan

[Han]

(12-13-2013 06:17 PM)Jonathan Cameron Wrote:  Thanks Han,

That was very helpful and I feel that helps answer several questions I had.

A couple more questions along these lines: Suppose you have a Solver-derived App and you set the equation by setting the value of E1 in the App code. Part 1: What is the correct syntax? Part 2: Suppose I edit the equation in the App [Symb] view. How can I restore the correct version of the equation as set in the App code? is there some way to "reset" an app back to original values? Or do i need a function for the App (via Menu perhaps) that resets all the equations?

-Jonathan

The easiest way to set E1 is via a string:

Code:

E1:="A*x+B*y-C=0"

I would make the operations explicit. Also ensure that the variables exist, otherwise you will get a Syntax Error. One may also use single-quotes (symbolic objects). So E1:='A*x+B*y-C=0' works just as well.

To reset the equations, you can use the [View] button. To set up the view list, you could do something like:

Code:


view "Reset all equations", RESET()
BEGIN
  E1:="A*x+B*y-C=0"; // default values here
  E2:="y=m*x+b"; // default values here
END;

When the user presses [View] they can choose "Reset all equations" to set the app to its default via the code for RESET(). You may also use START() in place of RESET() as this routine will always run when the app is first initialized.

[Bob Frazee]

I have a similar problem.
I us an App(customized Solve App) to call the Windchill program.
The WindChill program calls the following subroutines (functions?), all are EXPORTED.
IntroScreen: Uses variables DegF, Mph
InputScreen: Creates variable DegF, Mph
WindChillEqn: Uses variables DegF, Mph, Creates variables wct, wcto
FrostbiteEqn: Uses variables DegF, Mph, Creates variable ft
OutputScreen: Uses variables DegF, Mph, wct, wcto, ft
How do I allow all of these programs to share variables with out making them global? In a conventional programming language, I would pass them as parameters, ie WindChillEqn(DegF,Mph,wct,wcto,ft), but that procedure doesn't appear to work in this language. Any help would be appreciated.
rcf

[Han]

(12-13-2013 09:44 PM)Bob Frazee Wrote:  I have a similar problem.
...
How do I allow all of these programs to share variables with out making them global? In a conventional programming language, I would pass them as parameters, ie WindChillEqn(DegF,Mph,wct,wcto,ft), but that procedure doesn't appear to work in this language. Any help would be appreciated.
rcf

Is DegF a variable which must keep its value for all programs? In other words, if IntroScreen changes DegF, then is InputScreen supposed to use this new value? Or keep its own DegF? If all these programs are supposed to use a single value for DegF, then it would make sense to use a global variable. Just don't export it (if you don't want anyone other than the programs you wrote to mess with the values).

I have not had any issues passing parameters from one program to the next. The big question is whether the values passed should remain in the scope of the program to which they are passed vs. being kept for all programs to use. In order to properly call a subprogram, though, make sure to declare it before the program making the call. For example:

Code:


EXPORT global1, global2; // visible global variables
global 3; // hidden global variable

// declare subprograms here
SUBPRG1(); 
SUBPRG2(); 

EXPORT MAIN()
BEGIN
  LOCAL a, b, c, list;
  a:=1; b:=2; c:=3;
  list:=SUBPRG1(a,b,c);
  a:=list(1); b:=list(2); c:=list(3);
  list:=SUBPRG2(a,b,c);
  a:=list(1); b:=list(2); c:=list(3);
END;

// note the export
// this program becomes visible and usable by users
EXPORT SUBPRG1(a,b,c) 
BEGIN
  a:=2*a; b:=4*b; c:=8*c;
  RETURN({a, b, a});
END;

// note the lack of export
// this can only be called by other programs in this source file
SUBPRG2(a,b,c) 
BEGIN
  a:=a/2; b:=b/4; c:=c/8;
  RETURN({a,b,c});
END;

In the example above, we use a, b, and c as dummy variables for both subprograms. They are local variables and are destroyed when each subprogram returns to the main routine. Notice that in MAIN() I have to do lots of book-keeping in order to avoid global variables. Moreover, my subprograms must return lists in order to return multiple values. With global variables, you just declare them at the top and every program within the source file can use those variables. Excluding EXPORT just prevents users from messing with them.

[Bob Frazee]

Han;
Thanks for the reply. DegF and Mph are variables that keep their values for all the called programs within the WindChill program. I kinda follow what you did, but that method really makes the program complicated. It's not someplace where I really want to go. What I'm really attempting to accomplish is to keep DegF and Mph in memory, so when I restart the WindChill program, it reloads the previous values in those 2 variables. The EXPORT command as implemented now does that, but makes it too global. I think maybe I will explore creating a List to hold these 2 values.

You've given me some ideas to try. Thanks again.
rcf

[Han]

(12-14-2013 03:19 PM)Bob Frazee Wrote:  The EXPORT command as implemented now does that, but makes it too global. I think maybe I will explore creating a List to hold these 2 values.

You've given me some ideas to try. Thanks again.
rcf

How "global" did you want it to be? How precisely would you like the variables behave? Once we have settled this question, it will be much easier to decide which implementation is best.

The example I gave was to show just how messy using local variables would be, as you mentioned in an earlier post that you did not want to use global variables.

[Bob Frazee]

Han;
Thanks for being patient with me. My definition of global, is global to the WindChill program. The behavior of the variables would be as stated in post #7. Variables DegF and Mph are the two inputs that all the other values are calculated from. Those are the 2 values I would like to keep, and possibly a List file would be the best way to accomplish that. As an example, variable DegF is created in the InputScreen subroutine. It then needs to be passed to WindChillEqn, FrostbiteEqn,IntroScreen,and OutputScreen via the WindChill program, so I added DegF; to the WindChill program.

I had not declared my subroutines, as you show in post #8, so I tried that. I am still unable to get values passed. One thing that is possibly not clear is that the above subroutines are not part of the WindChill program file. They are 5 individual files in calculator memory. Possibly that makes a difference in the passing of variable values.
Thanks
rcf

[Han]

(12-15-2013 04:02 AM)Bob Frazee Wrote:  Han;
Thanks for being patient with me. My definition of global, is global to the WindChill program. The behavior of the variables would be as stated in post #7. Variables DegF and Mph are the two inputs that all the other values are calculated from. Those are the 2 values I would like to keep, and possibly a List file would be the best way to accomplish that. As an example, variable DegF is created in the InputScreen subroutine. It then needs to be passed to WindChillEqn, FrostbiteEqn,IntroScreen,and OutputScreen via the WindChill program, so I added DegF; to the WindChill program.

I had not declared my subroutines, as you show in post #8, so I tried that. I am still unable to get values passed. One thing that is possibly not clear is that the above subroutines are not part of the WindChill program file. They are 5 individual files in calculator memory. Possibly that makes a difference in the passing of variable values.
Thanks
rcf

Yeah, keeping them in one source file does make a difference, especially in the case of hidden global variables and the scope of EXPORT (for both variables and subroutines). Declaring subroutines is only relevant for subroutines that appear in the same source file. I believe those are only visible to programs declared within the same source file. So if you are calling programs from a different source file, then no declarations are needed. However, those other programs must be EXPORT'ed. That said, it is still possible to pass parameters to programs that are separated into many different source files. However, there are really only two ways I can think of:

1. EXPORT'ed global variables
2. Passing parameters via local variables in the receiving program

An example of 2, using separate source files:

In order to use separate source files, you would likely need to do something like:

File 1

Code:


globalvar1, globalvar2; // hidden global variables only within the scope of File 1

EXPORT MainProg()
BEGIN
  // keep globalvar1 as a list if you want simple code
  globalvar1:=Prog1(); // no need to declare at top
  globalvar2:=Prog2(globalvar1); // pass parameters to Prog2  
END;

File 2

Code:


// MUST BE EXPORTED!! otherwise it cannot be called by neither user nor other programs
EXPORT Prog1() 
BEGIN
  LOCAL a, b, c;
  // code that gets values for a, b, and c
  RETURN({a,b,c}); // use a list to return multiple values
END;

File 3

Code:


// MUST BE EXPORTED!! otherwise it cannot be called by neither user nor other 
EXPORT Prog2(list) // list becomes a local variable; auto-declared here
BEGIN
  // list(1) is the 'a' value passed from Prog1
  // list(2) is the 'b' value passed from Prog1
  // list(3) is the 'c' value passed from Prog1
  RETURN( /* insert what you want to be saved as globalvar2 */ );
END;

The variables globalvar1 and globalvar2 will retain their values the next time you run MainProg(). Any other subroutine coded inside File 1 will be able to use these two global variables. However, Prog1() and Prog2() cannot use globalvar1 and globalvar2 as they are not in the same scope (source file, if you will).

[Bob Frazee]

Han;
Thanks for the detailed answer. I'll keep plugging away at it, until I figure out something I'm satisfied with. You've provided me with some ideas to try.
rcf

[cyrille de brébisson]

Hello,

A Global variable is a variable that stays 'alive' even when all programs have stopped running.

A Local variable is a variable which live starts when the program execution reaches it's declaration and stops when the program execution exits the program block in which it was declared. (ie, when an END, ELSE or UNTIL is hit).

To execute a program/command, there are 2 phases: First, the text is read(parsed) by the calcualtor for the calculator to make sure that it undestands it. During that phase, the input text is transformed into internal calcualor language.
Then the calculator executes the instruction sequence in calculator language.

Global variable starts to exist when the calculator READS (parses) an input text, while local variable are execuion time only.


Now, in programs, you use both local variables (either declared as LOCAL or as input parameters) and global variables.

For global variables, you have 2 choices:
- EXPORTED and non-EXPORTED variables.
Use EXPORT when you want the variable to be accessible from OUTSIDE the program. Do NOT use EXPORT when the variable is only of interest to your program but should not be visible to the user.

cyrille