This functionality is supported only if you are using the Classic Agent.
You can change the way a script is initialized when it is opened, by setting the OldStartupFunction in the [Runtime] section of your partner.ini file. By setting the option to FALSE, you can have variables, windows, and other structures initialized in the order in which they are declared. When OldStartupFunction is set to TRUE, the default, windows are initialized before global variables. Therefore, you cannot initialize a window member from a global variable, regardless of how they were declared, but you can initialize a global variable from a window member.
If you have legacy scripts that run in distributed environments or on multiple platforms and that do not compile in this release, consider the two runtime options AutoGuiTarget and WinvarInitCorrectly. They deal with problems caused by the interaction of distributed testing and GUI-specific variable initialization. Set these options in the [Runtime] section of your partner.ini file.
You may find it useful to read about the GUI Targets field that appears on the Runtime Options dialog.
The following code produces a runtime error, because it is not possible to initialize the GUI-specific window member abc.ghi so that its value is correct for both the Windows 32 and Windows 9.x platforms:
window abc msw32STRING def = "1" mws9x STRING def = "2" msw32, msw9x STRING ghi = def
To avert this problem, the runtime option AutoGuiTarget was added. If set to TRUE, the default value, and when networking is not enabled, the GUI target is automatically set to the platform the test is running on. If it is FALSE or if the network is enabled, and if the GUI target includes both msw32 and msw9x, the code will continue to produce an error because no assumptions can be made about the GUI target.
If you are running in a distributed environment, where you might simultaneously connect to msw32 and msw9x, you must modify your code so that the variable (in the above example, abc.ghi) is defined for each individual platform.
In some cases, however, setting AutoGuiTarget to TRUE causes a problem. Consider the following code, which produces a compile-time error on Windows, because the GUI-specific window member abc.TF is defined only for msw32.
window abc msw32 TextField TF main () BOOLEAN bmsw32 = (GetGuiType () == msw32) ? TRUE : FALSE if (bmsw32) abc.TF.SetText ("some value")
When the GUI target excludes msw32, a compile-time error will result, because the variable abc.TF is defined only for msw32. When the GUI target includes msw32, the reference to abc.TF is never executed, and so a runtime error does not occur. However, when AutoGuiTarget is set to TRUE, the GUI target excludes msw32, and so the code will not compile. For this reason, WinvarInitCorrectly was added.
When WinvarInitCorrectly is set to TRUE, the default, window variables are initialized to allow correct operation in a distributed environment. When WinvarInitCorrectly is FALSE, window variables are initialized as if the only GUI that will ever be used is the one connected to when your script starts running. Any subsequent connections to other GUIs may see window variables that are initialized incorrectly or not at all.
Here are some guidelines regarding legacy scripts:
In a nondistributed environment set AutoGuiTarget to TRUE in order to run scripts resembling Example 1. However, if you have legacy scripts with code similar to both examples, set both options to FALSE, thereby restoring initialization behavior supported in earlier releases.