This topic describes some unexpected results that can occur when you use the ThruEvents method. When using this method it is recommended that you test on several machines that have different performance characteristics to ensure that you do not miss a timing issue on a particular machine.
1. Order in which event procedures are executed
The ThruEvents method generates the events that are waiting in the Windows message queue. In some cases, as shown in the example below, the order in which the events are invoked can be changed.
Example:
If the following three events are waiting and the ThruEvents method is invoked, the AddString methods are executed in the reverse order, so that "Rose", "Ken" and "Tom" are added to the ListBox control (LIST1).
First event:
INVOKE POW-SELF "ThruEvents" INVOKE LIST1 "AddString" USING "Tom"
Second event:
INVOKE POW-SELF "ThruEvents" INVOKE LIST1 "AddString" USING "Ken"
Third event:
INVOKE POW-SELF "ThruEvents" INVOKE LIST1 "AddString" USING "Rose"
Explanation:
When ThruEvents is invoked from the first event, the execution of the first event pauses while the other events in the queue are executed. So the second event starts, and similarly pauses while the third event starts. After the third event has paused for any other events, its AddString method is executed - adding "Rose" to the list. The third event completes so the second event can now continue and adds "Ken" to the list. The second event completes so the first event can continue and adds "Tom" to the list.
2. CloseForm in an event generated by ThruEvents
If you close the Form (e.g. by invoking the CloseForm method) in an event procedure that is generated by the ThruEvents method, the application ends abnormally.
To prevent this happening, you should check in the QueryClose event whether the event that invoked ThruEvents has stopped executing or not.
3. Same events generated in the queue
If you create code as shown below for a CommandButton click event, and quickly click the button several times, the same events are generated in the event queue.
When the ScriptLanguage property of the Module is "0-COBOL85 Language Mode" WK-COUNT is incremented more than you would expect.
For example, if you click the button 1 time the value of WK-COUNT will be 1,000,000, but if you click the button 2 times ThruEvents generates the 2nd click event and the final value will be greater than 1,000,000.
ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 WK-COUNT PIC S9(9) COMP-5. PROCEDURE DIVISION. MOVE 0 TO WK-COUNT. PERFORM 1000000 TIMES ADD 1 TO WK-COUNT IF FUNCTION MOD (WK-COUNT 1000) = 0 THEN INVOKE POW-SELF "ThruEvents" END-IF END-PERFORM. MOVE WK-COUNT TO "Text" OF TEXTBOX1.
Explanation:
Suppose you make the second click when WK-COUNT is at 300,000 in the first click event. The ThruEvents method pauses the first click execution and the code starts executing again for the second click. If you do not click again, the second click execution proceeds until WK-COUNT is 1,000,000 and control returns to the execution for the first click. However, with the ScriptLanguage property set to "0-COBOL85 Language Mode", the two events use the same data area for WK-COUNT. Therefore the first event continues adding to WK-COUNT, but WK-COUNT has jumped from 300,000 to 1,000,000. The first event executes another 700,000 iterations of the PERFORM statement, so WK-COUNT ends up with the value 1,700,000.
If the ScriptLanguage property is set to "1-00COBOL Language Mode" each event invocation uses a different data area for WK-COUNT and each click takes WK-COUNT to 1,000,000.