![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to mstest32.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [WindowsNT SDKs] / mstools / mstest|
Return to mstest32.txt CVS log | Up to [WindowsNT SDKs] / mstools / mstest |
1.1 root 1: HINTS FOR CREATING SCRIPTS FOR 32-BIT MICROSOFT TEST
2:
3: This file describes differences between using Microsoft Test on 16-bit Windows
4: vs. 32-bit Windows (NT). There are some areas where special code must be
5: placed into the scripts in order for script to successfully run under NT. In
6: almost all cases it is possible to create the scripts such that they will run
7: properly under both platforms without modification.
8: ------------------------------------------------------------------------------
9:
10: Due to differences between Windows 3.1 and Windows NT, MS Test scripts
11: written for 16-bit (Win 3.1) may not run under 32-bit without modification.
12: This file will explain some of the most common reasons for this and provide
13: ways to workaround the problems with simple modifications to scripts.
14:
15: The primary difference is preemption vs. non-preemption. Under 16-bit
16: windows, MS Test scripts could perform actions on an application with a
17: single statement, and be assured that by the time the next statement begins
18: to execute, the application has already completed what it was asked to do
19: with the first statement. For example, under Win 3.1 the code below:
20:
21: WMenu "File"
22: WMenu "Open..."
23: WButtonClick "Cancel"
24:
25: ...would bring up the File.Open dialog and cancel it without any problem.
26:
27: (Note that this is *most often* the case -- there are cases in Win 3.1
28: where the application "yields" while performing a task, in which case the
29: script writer must take special steps to ensure that task has completed
30: before continuing with the script.)
31:
32: However, the same code run on 32-bit windows will bring up the File.Open
33: dialog, but the WButtonClick function may fail because the File.Open
34: dialog may not be there yet. Since NT is a preemptive system, both
35: the application and the script run concurrently -- and if the application
36: takes longer to bring up the file.open dialog than it takes MS Test to
37: execute the WButtonClick call (which it often does), WButtonClick will
38: fail to find a "Cancel" button, the script will continue on, and we will
39: have effectively "lost" an important event.
40:
41: USING THE WFndWndWait FUNCTION:
42: -------------------------------
43: To combat this, 32-bit scripts need to WAIT for things to happen. By far,
44: the best way to do this is to use one of the new TestCtrl API:
45:
46: h = WFndWndWait ("Open", FW_PART, 5)
47:
48: This call will wait for a window with "Open" (or "open" or "OPEN") in its
49: caption to appear, or for 5 seconds, whichever happens first. The handle
50: to the window will be returned, or NULL if it timed out before the window
51: was found. When using this api, it is safe to use rather long timeout
52: values (20 or 30 seconds) because the function returns as soon as the
53: window is there, and if the window is expected to come up but doesn't,
54: something has gone wrong, anyway.
55:
56: Calls like this could be placed in between things that might take some
57: time to happen, like between "WMenu "File"" and "WButtonClick":
58:
59: WMenu "File"
60: WMenu "Open..."
61: h = WFndWndWait ("Open", FW_PART, 5)
62: WButtonClick "Cancel"
63:
64: AND, to make this even easier, you could create a wrapper function like
65: the following:
66:
67: DECLARE SUB WndWait (Title$)
68: STATIC SUB WndWait (Title)
69: IF WFndWndWait (Title$, FW_PART, giTimeOut) = 0 THEN
70: PAUSE "Window " + Title$ + " could not be found!"
71: END
72: END IF
73: END SUB
74:
75: ...and place it in a header file. Then all you need to add are statements
76: like the following:
77:
78: WMenu "File"
79: WMenu "Open..."
80: WndWait "Open"
81: WButtonClick "Cancel"
82:
83: ...and if the window you're looking for never comes up, the script will
84: END, after telling you which window it couldn't find.
85:
86: USING THE QueSetSpeed AND QuePause FUNCTIONS:
87: ---------------------------------------------
88: In some cases, slowing down playback of journalled events can be helpful, not
89: only in allowing things to complete (which isn't too much of a concern, since
90: NT synchronizes all input threads while journalling), but also in allowing
91: you to see what is actually happening during the execution of a script.
92:
93: You can do this in two ways:
94: - The QueSetSpeed statement allows you to set a time (in milliseconds)
95: delay between each message is played
96: - The QuePause stateent lets you set a one-time pause in the event
97: stream just before the next queued event.
98:
99: USING THE NEW SPEED STATEMENT:
100: ------------------------------
101: 32-bit MS Test has a new statement called SPEED which allows you to control
102: the general execution speed of the script. It is dynamic, meaning you can
103: run parts of the script at full speed, and slow other parts down drastically.
104: For example:
105:
106: SPEED 100
107:
108: ...will cause TestDrvr to sleep for 100 milliseconds before executing each
109: line of code in the script. Likewise,
110:
111: SPEED 0
112:
113: ...will allow TestDrvr to run the script at full speed.
114:
115: This can also be an easy way to keep the application under test from "falling
116: behind" the MS Test script. However, care should be taken when controlling
117: the speed of execution OR playback -- as it might work okay on one system, but
118: still be too fast for another.
119:
120: OTHER CONSIDERATIONS:
121: ---------------------
122: Some special things to watch out for include:
123:
124: - Using Program Manager to launch apps under test. Progman does NOT wait
125: for the application to come to the foreground before continuing. Thus
126: if you use "File.Run" from progman to start your app, you MUST use some
127: way of waiting for the application to appear before continuing with
128: the script, such as the WFndWndWait method. The best solution, though,
129: is to use MS Test's RUN statement. Internally, RUN uses WinExec, which
130: will wait until the application appears before returning, which causes
131: the script to wait as well. So, unless you are specifically testing
132: Program Manager's ability to launch applications, using RUN is a much
133: "safer" way of starting the app.
134:
135: - Switching between apps within the script (such as setting focus to
136: another application, etc). You should wait for a brief moment (perhaps
137: SLEEP 1 to sleep for a second) before starting to perform actions to
138: the new app.
139:
140:
141: WS1.DLL - WaitUntilIdle() FUNCTION:
142: -----------------------------------
143: The following function is provided in the WS1.DLL:
144:
145: DECLARE FUNCTION WaitUntilIdle LIB "ws1.dll" (nMSecToWait&) as Integer
146:
147: The WaitUntilIdle function waits until the forground application has reached an
148: idle state.
149:
150: Parameters: nMSecToWait& -
151: Specifies the number of milliseconds the function will wait for
152: the foreground application to go idle.
153: 0 : Function tests the idle state and returns immediately.
154: -1 : Function will not return until the idle state is reached.
155:
156: Return Value: TRUE : The foreground application reached the idle state.
157:
158: FALSE : The wait was terminated because the timeout time was
159: reached or an error occurred.
160:
161:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.