Prime app variables
|
12-13-2013, 03:33 PM
Post: #1
|
|||
|
|||
Prime app variables
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:
2. How do I define and use app-specific variables? For instance, if I define like this: Code:
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 |
|||
12-13-2013, 04:02 PM
Post: #2
|
|||
|
|||
RE: Prime app variables
Your understanding of how app variables work is just fine. The only notes I can add are:
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. Graph 3D | QPI | SolveSys |
|||
12-13-2013, 05:27 PM
Post: #3
|
|||
|
|||
RE: Prime app variables
(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 |
|||
12-13-2013, 05:42 PM
Post: #4
|
|||
|
|||
RE: Prime app variables
(12-13-2013 05:27 PM)Jonathan Cameron Wrote: Thanks Han, 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:
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. Graph 3D | QPI | SolveSys |
|||
12-13-2013, 06:17 PM
Post: #5
|
|||
|
|||
RE: Prime app variables
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 |
|||
12-13-2013, 07:28 PM
Post: #6
|
|||
|
|||
RE: Prime app variables
(12-13-2013 06:17 PM)Jonathan Cameron Wrote: Thanks Han, 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:
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. Graph 3D | QPI | SolveSys |
|||
12-13-2013, 09:44 PM
Post: #7
|
|||
|
|||
RE: Prime app variables
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 |
|||
12-14-2013, 02:36 AM
Post: #8
|
|||
|
|||
RE: Prime app variables
(12-13-2013 09:44 PM)Bob Frazee Wrote: I have a similar problem. 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:
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. Graph 3D | QPI | SolveSys |
|||
12-14-2013, 03:19 PM
Post: #9
|
|||
|
|||
RE: Prime app variables
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 |
|||
12-14-2013, 09:19 PM
(This post was last modified: 12-14-2013 09:20 PM by Han.)
Post: #10
|
|||
|
|||
RE: Prime app variables
(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. 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. Graph 3D | QPI | SolveSys |
|||
12-15-2013, 04:02 AM
Post: #11
|
|||
|
|||
RE: Prime app variables
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 |
|||
12-15-2013, 04:37 AM
Post: #12
|
|||
|
|||
RE: Prime app variables
(12-15-2013 04:02 AM)Bob Frazee Wrote: Han; 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:
File 2 Code:
File 3 Code:
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). Graph 3D | QPI | SolveSys |
|||
12-16-2013, 12:40 AM
Post: #13
|
|||
|
|||
RE: Prime app variables
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 |
|||
12-16-2013, 08:02 AM
Post: #14
|
|||
|
|||
RE: Prime app variables
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 |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: