#Include Statements and How They Work

Keywords: 	 #include Include Call Library 111 execution error encrypted encoded verification failed

#Include is a preprocessor statement that gets executed before the Winbatch processes the first statement. Therefore #include cannot be conditionally loaded as proven by the script below. Note: The WB Studio Debugger converts #include into Call statements so that they can be debugged.

;; Create an file to include
strData = "#definefunction foo()":@CRLF
strData = strData:"Message('In Foo', 'Bar')":@CRLF
strData = strData:"#endfunction":@CRLF
FilePut( "foobar.wbt", strData )

x = 1
If x == 0
#Include "foobar.wbt"
EndIf

;; Errors if foobar.wbt contents not processed. (IT IS ALWAYS PROCESSED BEFORE THE SCRIPT EXECUTES ITS FIRST LINE)
foo()

FileDelete("foobar.wbt")

Question:

My topic title sounds quite weird, but here is my issue:
I have built a function framework in Winbatch with about 40 function libraries (from low-level to high-level function libraries), where the high-level libraries use functions of the low-level libraries (and therefore include these scripts).
As different high-level libraries include the same low-level libraries (eg. logging, file operations, ...), a main script that includes some of these high-level libraries (indirectly) includes the low-level libraries several times.
The way I do this is a clean solution (data encapsulation, independent modules), but it has become a performance issue: Including one (very, very) high-level library now takes 28 seconds !!!
Helpful would be some sort of #ifndef or an intelligent WinBatch interpreter that checks the loaded scripts before executing another include.
To the support team: Could something like that be integrated into one of the next versions of WinBatch?
To all: I am thinking of refactoring the framework and switching from #include to call (and checking if the script has been loaded before executing the call).What do you think about this "workaround"? What are the risks of doing so?
Short sample to illustrate this:
LibA includes nothing LibB includes LibA LibC includes LibA and LibB LibD includes LibA and LibC The main script includes LibD and LibB So the includes will be resolved like that: LibD,LibA,LibC,LibA,LibB,LibA,LibB,LibA - 8 includes for 4 libraries
In our framework this scenario explodes and leads to a timespan of 28 seconds for including one big library! Advantage of this architecture is the modularity - you just include those libraries your script will call directly. And I don't want to lose this advantage.
I have just written a small script that shall be called instead of #INCLUDEing the libraries. This script will check if the library to be included is already loaded (using IntControl(77,103, 0, 0, 0)). If not, the library will be loaded using Call. It was not as easy as it sounds, because I wanted to keep the advantage of modularity and therefore this script will be called recursively from every loaded library (and I had to make sure that the variable values within this script will not be overwritten when it is being called recursively).
But it seems to load all libraries and this just takes about 1 second!!! :-)

I still have to test this solution in detail, but it seems very promising...

Answer:

Yes, when you execute a script using 'WinBatch.exe' or one if its manifest variants, the #include expansion happens *before* the interpreter processes a single statement. The process of expansion cannot be be prevented by using gotos or conditionals because it happens before the interpreter is called to process any WIL statements.

There are at least two ways around the issue.

Use the WinBatch compiler. The compiler will expand and optimize #includes during the compiling process so you don't incur the upfront load time penalty at startup. However, this approach does not fully remove the execute time penalty of having to re-execute the same lines over and over.
A second solution would be to place the #include statements in a separate Called WinBatch script. The interpreter handles the processing of #include statements in called scripts instead of WinBatch.exe so you can control the #include process in a called script by conditionally executing the Call statement. Of course, the obvious question here is why not just use the Call statement on the otherwise #included files in the first place.

Then there is the whole issue of WinBatch Studio which handles #include in an entirely different way. In short it basically converts #included into Calls.

We are working on a solution. Until something better comes along, I guess you will have to stick to 'Call'.

Question:

I am trying to put some '#include' stmts in my winbatch script, which is actually a dialog box, and ran into some problems.
My script looks like this:
addextender... #include "d:\\wbscriptb.wbt" ...bunch of other code setting up the ... dialog box..getting an answer switch case x call("wbscriptb"."") break ..rest of code
I then compile (99g) and the main menu comes up ok, but when i get:
111 execution error. encrypted/encoded verification failed.
Then when I click on that msg it actually brings up the file i '#include'd, without going through the dialog and asking me to make a selection.
Is there something magic about #includes that they can't all be at the beginning of the program and then let me call them as i need them?

What i envisioned was just having all the includes at the beginning, like assembler language, then having one big module result.

Answer:

Sort of kind of.

#Includes COPY the code right there (in place) into your program (in compiled mode anyway) It almost like copying and pasting the code into the script. You can't "CALL" the code you included, but you can GOSUB routines in it.
If you put all the includes up on top, be sure to do a GOTO around the #include statements so they do not get executed when the script starts up
Alternatively you can "encode" your sub-wbt files with the compiler, then when you compile the main program as an exe, include all those WBC files into the large exe you are making.

I think what is going on is that although some code got included in your exe, your call statement went out looking for a WBT file, found the actual file (nothing to do with the include) and tried to run it.

CALL's in a compiled EXE cannot run RAW exe files (they have to be encoded into WBC's first).

Question:

hmmm...on reading the answer again, is it possible that i can't call an #include'd wbc?
if i do this: #include "d:\..\sname.wbc"
will i be able to do this: call("sname.wbc","")

or did the part about only being able to gosub only apply if i am copying in a raw wbt?

Answer:

Right. You can't do it *that way*. However you may be able to do it *other ways*.

There is a problem in the definition of "referenced".

Consider the #include statement to be "executable". It is a line of code and it WILL execute just like all other lines of code.

If you include a WBC file it is executed right then and there. You cannot call the WBC file later in your script and expect it to have anything to do with the #include'd file.

Question:

I'm seeing something I've never seen before. I wrote a UDF and placed it in a separate file (we'll call it UDF_1.wbt). In my main program (I'll call it MAIN) I do a #include UDF_1.wbt near the top (prior to it being called of course). I compiled MAIN and ran it from the system I was developing on. Worked fine.
Took the MAIN.exe to another system to run. I'm getting a 217 error saying it can't process the include file UDF_1.wbt.
Now I thought that anything #include'd was sucked in at compile time and therefore did not have to be present at runtime. I checked the docs but can't find any mention of this being different for UDFs.

Any idea what's happening?

Answer:

Post the *exact* code of the UDF. Read the #include docs.

Somehow I think it did not get properly included.

What happens is that there can be two attempts to process a #include.

On the first attempt it tries to suck it in and make it part of the script. However if that fails for some reason (improperly coded #include ), then later, at execution time if it sees a #include it kind of tries again. The second time it needs the file.

The second pass is more forgiving than the first pass.

-----

#include "filename":

The keyword "#include" must be all lower-case.

The file name must be delimited by double quotes.

The file name may contain path information. Nothing else should appear on the line. -----------

Maybe put double quotes around the file name.

Article ID:   W14216

Filename:   Include Statements - How They Work.txt

File Created: 2013:02:15:09:21:34

Last Updated: 2013:02:15:09:21:34

Database Search

TechHome

#Include Statements and How They Work

Question:

Answer:

Question:

Answer:

Question:

Answer:

Question:

Answer:

	Compiling XLS and Running as a Service
	Sample Code from Users