Is there method to include other file?

If “A” file contains some definitions of variable that I want to access in file “B”.How to use SenseTalk statement to include file “A” in file “B”?Just like “include” in C language and “source” in Bash.

I have 3 suggestions, each with it’s own advantages and disadvantages:

  1. You can share values by declaring the variables as “global” (or perhaps “universal”. There’s a discussion of the different variable types at http://www.testplant.com/phpBB2/viewtopic.php?t=1836. While the examples shown in that post are of handlers within a script, the same rules apply to other scripts (in fact, all scripts are themselves handlers.) You have to declare the variable as global in each handler in which you want to access it. Changing the value of the variable anywhere changes it everywhere.

  2. You can also pass values from one script to another. Put a line like the following at the top of script B:

params myVar1, myVar2

and call script B from script A like this:

B "someString", (a, list, of, values)

then in script B you can access those values:

click myVar1
repeat with each item of myVar2
    put it
end repeat

Unless you explicitly pass the values by reference, only the values are passed.

  1. You can do a form of include using the “do” command. “Do” takes any string that contains syntactically correct SenseTalk and runs it as code. That string could be a single command or it could be a whole script. So if you want to “include” script B in script A, you could use a command like this:
do file "/path/to/script B"

This will read the contents of script B and execute them as part of script A. If you wanted to include script B in both script A and script C, and you wanted script B to define variables, you would still need to declare those variables in script B to be global or else scripts A and C would each have their own copy of the variables.

This last option is also tricky because if you declare global variables and assign them values in script B, anything you do to those variables in script A would get overwritten by including script B in script C, since script B would be executed a second time, including the initialization of the global variables.

This approach is probably a good option if you use local (not global) variables and you just wanted to define some constants like an exchange rate or a username.

Let us know if you have any other questions.

Thanks Matt.

In my script,I got the same effect from command “run”.Both “run” and “do” are available to my case,because I just want to refer to some variable,won’t modify them.

The only way what you describe is possible is if you are using global variables (which you may be doing) – if you’re not using globals then declaring or initializing a variable in a script that you execute using “run” will create that variable only in that other script, not in the calling script. The “do” method makes the executed script a part of the script that contains the “do” command, so all of the second script’s variables are part of the first script’s context.

This effect can be easily demonstrated in 3 lines of code in 2 scripts. The “run” method:

Script1:
run script2
put myRemoteVar

Script2:
set myRemoteVar to "oregano"

When script1 is run, it will output the string “myRemoteVar” because the variable will not be set in script1 by the line in script2 – they are two local variables being used in their own separate contexts.

The “do” method:

Script1:
do file "/path/to/script2.script"
put myRemoteVar

Script2:
set myRemoteVar to "oregano"

When script1 is run in this case, the output will be “oregano” because the above has worked like an include, so that the code being executed within script1 is actually:

set myRemoteVar to "oregano"
put myRemoteVar

And it is all executed in the context of script1.

That’s an excellent example, Matt, that perfectly illustrates the key difference of “do”.

I thought I’d add one additional note in a more technical vein for any really hard-core readers out there…

Because it’s evaluated in the local context, “do” is close to being like the “include” mechanism in other languages, but with an important distinction. Most “include” or “import” mechanisms read another file at compile time and include the text of that file as part of the code being compiled. SenseTalk’s “do” is a runtime mechanism, called after the local handler has been compiled. So code called by “do” can set the value of local variables, but it can’t usefully declare lists of global or universal variables.

Hello guys,

Command “file do” just handle scripts that variables were defined within.But not recognize scripts that handler defined within.
For example:
scritpA in suiteA:
set global TargetIP to “10.64.2.99”
call do command:
do file “scriptA” //OK

scriptB in suiteB:
to MyClick ImageName

end MyClick
call do command:
do file “scriptB” //Fail
Selection Failed in 0:00:00 SenseTalk Compiler Exception in :
Syntax Error at line 9: Syntax Error - can’t understand “to” at or near character 78

After read many threads,I have to do as below:
OpenSuite “/path/to/suiteA”
OpenSuite “/path/to/suiteB”
run “scriptA”
start using “scriptB”

Certainly,we could use command “file” for scriptA instead of “OpenSuite”.

All of above,it looks like a little troublesome.

What you’re suggesting doesn’t work because the “do” command executes the text argument, but you can’t execute a handler declaration (which is what the “to” is in your example). You can execute the code inside a handler, but you can’t execute the declaration. That’s why you get an error when you pass a script including handler definitions to the “do” command.

You can use OpenSuite as you found, or you can add the suite B to suite A (or vice versa) as a Helper, or you can add one suite to another by adding it to the initialSuites. But note that when you “run” another script, all that gets executed is the code up to the first handler definition; this is called the initial handler. All scripts are themselves handlers. So even if you have handlers defined in the script that you run, the handlers are effectively ignored unless they are called specifically.