Call Versus Include

There are some subtle differences between Call and #include:

Call is executed at runtime and #Include is a pre-processor directive.
Called scripts (.wbc) must be distributed along with the calling exe. When using the WinBatch compiler, the "included" file(s) must be present at compile time; they will be embedded in the compiled EXE, and therefore do not need to be distributed as separate files.
WinBatch Studio debugger does not process #includes directly, and secretly converts them to a call when debugging.
Call() looks at the current drive/directory at that point of execution, not at script launch time. For example, you can do:
```
DirChange(DirScript())
Call("script","")
```
and it will find the script in the same dir as the source code, regardless of where you are running the script from. There is no way to do this with #include.
Call can pass parameters and #include doesn't. If a string of parameters is passed to the secondary WIL batch file, using the Call command, it will automatically be parsed into individual variables with the names param1, param2, etc.

Question:

I'm curious what differences there are betweene the Call and #Include in interpreted [not compiled] scripts. (i.e., that have been documented/known by the various WB experts over the years).
I can think of two:

Call() is runtime, not interpret-time, so filenames are evaluated w.r.t. the current drive/directory at that point of execution, not at script launch time. For example, you can do: DirChange(DirScript())/Call("script","") and it will find the script in the same dir as the source code, regardless of where you are running the script from. As far as I know, there's no way to do this with #include.

Since #include is textual, you could do a goto from within the #include'd script to a label in the parent script. As far as I know (haven't tested), you can't do this with Call() (with the standard caveat, of course, that you shouldn't want to...)
Are there any other artifacts of #include being strictly textual?

Answer:

Yes, that is pretty much it, the #include in the debugger cannot "reach out" of the #included file like a true #include can, but indeed, you should not do that anyway.

Ummm there is also that you can use %substitution% variables in Calls but not in #includes.

A corollary says you can do

#include %somefilenamevar%

in the WinBatch Studio debugged, not not in real Winbatch code. But you should not anyway.

In general, just because something works, does not make it recommended or a desirable programming technique. Indeed, there are horrible programming techniques that can be done that, well, work fine. Thankfully most people, when they find one, are sensible enough not to exploit it.

Article ID:   W16966

File Created: 2007:07:03:14:27:22

Last Updated: 2007:07:03:14:27:22

Database Search

TechHome