WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Variables and Parameters

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Passing Parameters between WBT's

Keywords:     passing parameters

Question:

Is it possible to pass a variable to another winbatch script?

Answer:

Yes. You can pass parameters between Winbatch scripts.

If you CALL another another script:

  1. You can pass variables in the call statement, and they show up as param1 param2 etc (param0 tells you how many you have).

  2. All variables (including param1 etc) are global anyway so both scripts can see them (and trash them for the other script if you are not careful).
If you RUN or RUNWAIT another script, you can pass variables as above, but there are independent variable pools. It is a bit tougher to get data back the the originating script. (you'll have to use an INI file).

If you are:

  1. Using the Interpreter

    and

  2. Want to use the RUN method

    THEN you need a fully qualifies run statement, ala:

    wbexe=WinExeName("")
    WBTfile="my.wbt"
    params="123 fred and-som-more-parameters"
    Run(wbexe,strcat(wbtfile," ",params))
    

More examples:

Variables are global between "Call"ed Winbatch scripts. The following explains how two separate scripts might share variables:

The first WBT contains, for example:

;first.wbt

	a=5
	b=6
	
	call("second.wbt","c %a% %b%")
	Message("%a% plus %b% is",c)
	call("second.wbt","d %a% %b%")
	Message("%a% plus %b% is",d)
	exit
And the second WBT might contain:
;second.wbt

	temp=param2+param3
	%param1% = temp
	return
In "official computerese", WinBatch generally passes functions by "value". In this case, by passing the name of a variable "c", and then "d", we are faking a "pass by reference". The subroutine, second.wbt, stores the result of the computation into the variable by reference.

Watch the "c" and "d" variables closely.

There are (at least) five ways to pass information from a called WinBatch EXE back to the calling WinBatch EXE:

  1. Via an INI file (IniWrite[Pvt] / IniRead[Pvt])

  2. Via a text file (FileWrite / FileRead)

  3. Via a file name (FileCopy or FileRename / FileExist)

  4. Via the clipboard (ClipPut / ClipGet)

  5. Via a window (Display or Message / MsgTextGet)
Each method involves a write/read function pair (shown in parentheses): First, the called EXE places the desired information in an accessible location using the "write" function, then the calling EXE retrieves the information using the "read" function.

Here is an example using the first (INI) method, since it's easy, clean, efficient, and safe:

  ; MAIN.WBT (which can be compiled to an EXE)
  number = AskLine("SquareIt", "Please enter a number:", "")
  If number == "" Then number = 0
  
  RunWait("squareit.exe", number)    ; if you're runwaiting a compiled WB WBT
  
  ;Or, here's how you'd run it, if you're runwaiting an uncompiled WB WBT: 
  ; RunWait("c:\progra~1\winbatch\system\winbatch.exe", "squareit.wbt %number%")
  
  result = IniRead("SquareIt", "Result", "")

  Message("SquareIt", "%number% squared is %result%")
and the second WBT:
  ; SQUAREIT.WBT (which should be compiled to SQUAREIT.EXE)

  square = param1 * param1
  IniWrite("SquareIt", "Result", square)  
or

Associate a file type as you normally would by using File Associate except choose the WBT or WBT.EXE which launchs the application instead.

To pass parameters your code should look like:

        RunWait("Winword.exe", "%param1%")
If a DOC file is clicked on in the File Manager the filename will be passed as param 1.

To keep the application from failing when launched from an icon add the following line above the run statement to define param 1.

        If Param0==0 then Param1=""

Another Question:

I have a problem with using CALL() and passing arguments. My understanding was that arguments get passed as param1, param2, etc., with param0 giving a count of the number of such arguments. But while param1, etc. do seem to contain the correct values, param0 always seems to be just equal to 0. So I can't test for the existence of arguments by saying "If param0 > 0 Then", or whatever.

Any explanation?

Answer:

If you use Call ("whatever", "") then "whatever" will not change any variables (eg: param1, param2, etc.). However, param0 is a variable that is generated by each and every program as it is run or called, and it is generated to be the number of space-delimited parameters on the calling command line.

Therefore no matter whether param1, param2, etc. have values or not, the above Call will create param0 = 0, and this will remain in effect when you leave the program and go back to the originating program.

Note that Call ("whatever", "parm1 parm2 parm3") creates param0 = 3, param1 = parm1, etc, but that if you previously had param4 and param5 they will remain. When you get back to the calling program, param1, param2 and param3 will remain param1, param2, etc.

PS--> Call ("whatever", "a very long set of parameters over 9 words in length") produces within whatever param1 - param9 with param9 being the word "words", but param0 is equal to 11 (no warning or error message)

Be aware that param0, param1, etc are GLOBAL variables and that if you do a CALL to a subroutine then return, the values of param0 etc are the values passed to the subroutine, not the ones on original entry to the program. If you wish to preserve them you must save them before doing a call.


Article ID:   W13914
Filename:   Passing Parameters between Called WBTs.txt
File Created: 1999:04:15:16:57:14
Last Updated: 1999:04:15:16:57:14