In my last post, I promised I would go into further detail on how setting the synchronous boolean to ‘False’ can essentially hose up your script.
So remember I said that when using these message codes you will want to set the synchronous boolean to ‘True’. At first, whenever using this function I set the boolean to ‘False’ and noticed no difference. In fact, it almost seemed like setting to ‘False’ provided better performance because setting to ‘False’ meant we aren’t waiting for the user interface to process the message before going on. However, I was actually able to get TestStand to lock up with a very practical scripting implementation that thoroughly convinced me to always set that boolean ‘True’. Allow me to explain.
Suppose that during test execution you decide to disable sequence tracing because you have limited CPU resources or the Sequence Call you are calling is being launch via a new thread. Figure 1 below shows an example of me modifying the Sequence Call such that tracing is disabled.
Figure 1
Now with the boolean variable still set to ‘True’, I’m going to execute my sequence once again.
Figure 2
Figure 2 shows that my progress bar continues to update properly even though tracing is disabled. Now let me see the boolean to ‘False’ for both the progress indicator and progress text and re-execute the script. Below are my results.
Figure 3
Figure 3 shows that after my Sequence Call has finished executing, my progress bar only shows 15 seconds had expired and only 25% was completed. Therefore, the user interface couldn’t process the progress bar updates fast enough. On top of that, the TestStand engine completely froze and I had to go into task manager to kill the process.
So there you have it! Modifying the progress bar can be pretty useful for the end user on the current execution status of a test script. However, as with all things when you are modifying the TestStand user interface, you have to be aware of the traps a future script change could expose to your code.