Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How can one script pass and return values to another script?
Language Reference
How can one script pass and return values to another script?
In my experiences, I have found that there are basically three ways to accomplish this task. Each method has its own pros and cons, so the developer will need to determine which method best suites their needs.
Method 1 û Environment variables
Lets start from the beginning. Most scripting developers know about the shell object provided to us by Microsoft. If you do not know about this object, then I recommend that you gather that information before continuing with this FAQ.
Here is a simple program calling another program named called.vbs.
Here is the code for C:\called.vbs.
Executing this code will display two message boxes. The first will display a message "ThisIsValue1", the second will display "This is value 2".
Note a few things. First, you can pass values in the command string itself, or concatenate variables to the end of your string. Either way, each value being passed to the called program must be delimited by a space. Also note that in the called program, each value is stored in the array Wscript.Arguments.Item with the first value beginning in element 0.
Now what about returning a value from the called program back to the calling program? Well, to my knowledge, the shell object or any other built in VB function does not allow this. As the title of method one indicates, we must use environment variables. If you are not familiar with environment variables, then I recommend that you gather that information before continuing with this FAQ.
If you are familiar with VB routines, you will remember that arguments included in the routine declaration will allow you to pass values "by value" or "by reference". If you want to pass values "by value", then I recommend passing them as mentioned above. However, if you want to pass values "by reference", then you will need to put them in environment variables that can be updated by the called program. After executing the called program, the calling program simply needs to read those same environment variables and continue processing. The only concern here is that you will need to coordinate between the scripts what the names of your environment variables are. However, with careful consideration to your coding standards, this shouldnÆt be too difficult. Ok, here is an example for using environment variables.
The called program.
Executing this code will display two message boxes. The first will display a message "This new value is 2". The second will display the message "This value contains: This new value is 2".
Note first the declaration of objEnv, that it references "User". If you look at your environment variables via the advanced system properties, you should see two areas where variables are stored. The first is "User variables for [userid]". The second is "System variables". Reference each area by "User" and "System" respectively. Next, notice that you reference the variable by surrounding it with percent signs "%". ThatÆs just a Microsoft thing
. The second message box shows how you can automatically concatenate another string value with the return value of the system variable. Finally, note that you declare a new system variable the same way you update an existing one. This may open the door for potential problems, but careful coding should alleviate this.
An idea that may help to control the names of your environment variables is to pass the variable name itself in your run statement, and use the passed value to read the appropriate environment variable. HereÆs an example for the calling program.
The called program.
Even though this may be an interesting solution to pass values from one script to the next, it may not always be the best.
Method 2 û WSH (Windows Script Host) scripts
A .wsh script is another of the many types of scripting extensions that Microsoft provides us. To create a script like this, you will actually need to use XML coding in addition to normal VB script. One particular advantage to this method is that Jscripts and other scripting languages supported by Microsoft can be used in a .wsh file, opening the door to many new opportunities.
The basic idea with passing values in a .wsh script is that you donÆt actually pass values from one script to another, instead you simply include the called script within the calling script. If you declare "var1" in the calling script, you do not need to include a declaration statement for "var1" in the called script. You simply reference the already declared variable. Potential problems may arise in terms of variable scope. If you declare the same variable in both the calling script and the called script, results may be unpredictable. However, careful planning of your code can side-step this problem.
Here is the code for C:\called.vbs.
Here is the code for C:\calling.wsh.
Executing this code will display a message box with the message "This is modified value 2".
There are a couple things to note here. First, note that called.vbs does not declare var1. If you use OPTION EXPLICIT in this script, you will be forced to declare var1, which may cause problems. Typically, this method is used for including functions, or calling routines from other programs, but not just for passing variables. The other thing to note is that the include statement should come before the rest of the coding.
Method 3 û WSC (Windows Script Component) scripts
A .wsc file is very similar to a .dll file in that you can create object references to the code in the .wsc file. One big difference is that .wsc files can be created and registered without the use of a full compiler like VB Studios. Like the .wsh file, the .wsc file uses XML to wrap around the scripting code, which can be any Microsoft supported scripting language. For larger projects, this is probably the best solution. It will allow the calling script to truly call a function in the .wsc (called) file and expect a return value as if it called a function within its own script.
With a .wsc file, there are many things that can be noted here. Because of time and space constraints in this FAQ, I will direct you to Microsoft's site, which has detailed examples on creating a component file. Please refer to the following site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsobjwshshell.asp
In conclusion, the developer needs to be aware of the multitude of possibilities provided by VB Scripts and use the method that best suites the needs of their system.
Good luck!
In my experiences, I have found that there are basically three ways to accomplish this task. Each method has its own pros and cons, so the developer will need to determine which method best suites their needs.
Method 1 û Environment variables
Lets start from the beginning. Most scripting developers know about the shell object provided to us by Microsoft. If you do not know about this object, then I recommend that you gather that information before continuing with this FAQ.
Here is a simple program calling another program named called.vbs.
Code:
Dim objShell, value2
Set objShell = Wscript.CreateObject("WScript.Shell")
value2 = "This is value 2"
objShell.Run "C:\called.vbs ThisIsValue1 " & value2
Set objShell = Nothing
Code:
MsgBox Wscript.Arguments.Item(0)
Msgbox Wscript.Arguments.Item(1)Note a few things. First, you can pass values in the command string itself, or concatenate variables to the end of your string. Either way, each value being passed to the called program must be delimited by a space. Also note that in the called program, each value is stored in the array Wscript.Arguments.Item with the first value beginning in element 0.
Now what about returning a value from the called program back to the calling program? Well, to my knowledge, the shell object or any other built in VB function does not allow this. As the title of method one indicates, we must use environment variables. If you are not familiar with environment variables, then I recommend that you gather that information before continuing with this FAQ.
If you are familiar with VB routines, you will remember that arguments included in the routine declaration will allow you to pass values "by value" or "by reference". If you want to pass values "by value", then I recommend passing them as mentioned above. However, if you want to pass values "by reference", then you will need to put them in environment variables that can be updated by the called program. After executing the called program, the calling program simply needs to read those same environment variables and continue processing. The only concern here is that you will need to coordinate between the scripts what the names of your environment variables are. However, with careful consideration to your coding standards, this shouldnÆt be too difficult. Ok, here is an example for using environment variables.
Code:
Dim objShell
Dim objEnv
Set objShell = WScript.CreateObject("WScript.Shell")
Set objEnv = objShell.Environment("User")
objEnv("var1") = "This is value 1"
objShell.Run "C:\called.vbs"
MsgBox objShell.ExpandEnvironmentStrings("%var1%")
MsgBox objShell.ExpandEnvironmentStrings("This value contains: %var1%")
objEnv.Remove "var1"
Set objShell = Nothing
Set objEnv = Nothing
Code:
Dim objShell
Dim objEnv
Set objShell = WScript.CreateObject("WScript.Shell")
Set objEnv = objShell.Environment("User")
If objShell.ExpandEnvironmentStrings("%var1%") = "This is value 1" Then
objEnv("var1") = "This new value is 2"
End If
Set objShell = Nothing
Set objEnv = NothingNote first the declaration of objEnv, that it references "User". If you look at your environment variables via the advanced system properties, you should see two areas where variables are stored. The first is "User variables for [userid]". The second is "System variables". Reference each area by "User" and "System" respectively. Next, notice that you reference the variable by surrounding it with percent signs "%". ThatÆs just a Microsoft thing
. The second message box shows how you can automatically concatenate another string value with the return value of the system variable. Finally, note that you declare a new system variable the same way you update an existing one. This may open the door for potential problems, but careful coding should alleviate this.An idea that may help to control the names of your environment variables is to pass the variable name itself in your run statement, and use the passed value to read the appropriate environment variable. HereÆs an example for the calling program.
Code:
objEnv("var1") = "This is value 1"
objShell.Run "C:\called.vbs var1"
Code:
Dim varName
varName = Wscript.Arguments.Item(0)
If objShell.ExpandEnvironmentStrings("%" & varName & "%") = "This is value 1" Then
objEnv(varName) = "This new value is 2"
End IfEven though this may be an interesting solution to pass values from one script to the next, it may not always be the best.
Method 2 û WSH (Windows Script Host) scripts
A .wsh script is another of the many types of scripting extensions that Microsoft provides us. To create a script like this, you will actually need to use XML coding in addition to normal VB script. One particular advantage to this method is that Jscripts and other scripting languages supported by Microsoft can be used in a .wsh file, opening the door to many new opportunities.
The basic idea with passing values in a .wsh script is that you donÆt actually pass values from one script to another, instead you simply include the called script within the calling script. If you declare "var1" in the calling script, you do not need to include a declaration statement for "var1" in the called script. You simply reference the already declared variable. Potential problems may arise in terms of variable scope. If you declare the same variable in both the calling script and the called script, results may be unpredictable. However, careful planning of your code can side-step this problem.
Here is the code for C:\called.vbs.
Code:
Sub subTest()
var1 = "This is modified value 2"
End Sub
Code:
<job id="Main">
<script language="VBScript" src="C:\called.vbs" />
<script language="VBScript">
Dim var1
var1 = "This is value 1"
Call subTest
MsgBox var1
</script>
</Job>There are a couple things to note here. First, note that called.vbs does not declare var1. If you use OPTION EXPLICIT in this script, you will be forced to declare var1, which may cause problems. Typically, this method is used for including functions, or calling routines from other programs, but not just for passing variables. The other thing to note is that the include statement should come before the rest of the coding.
Method 3 û WSC (Windows Script Component) scripts
A .wsc file is very similar to a .dll file in that you can create object references to the code in the .wsc file. One big difference is that .wsc files can be created and registered without the use of a full compiler like VB Studios. Like the .wsh file, the .wsc file uses XML to wrap around the scripting code, which can be any Microsoft supported scripting language. For larger projects, this is probably the best solution. It will allow the calling script to truly call a function in the .wsc (called) file and expect a return value as if it called a function within its own script.
With a .wsc file, there are many things that can be noted here. Because of time and space constraints in this FAQ, I will direct you to Microsoft's site, which has detailed examples on creating a component file. Please refer to the following site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsobjwshshell.asp
In conclusion, the developer needs to be aware of the multitude of possibilities provided by VB Scripts and use the method that best suites the needs of their system.
Good luck!