|
|
AfterDisplay script
Posted: 14 Oct 09 3:15 AM
|
I am running into situations in which my AfterDisplay scripts seem to be executing before the prompt has completed its display. It is as if the event related to displaying all the prompt elements does not complete before the AfterDisplay script begins execution.
The only similar situation I can relate to you is another language I work in with threading capabilities, such as Java, where imprecise control of the threads can produce unexpected results.
Specifically, I am relying on any given prompt displaying all its elements, so their state(s) can be referenced before my AfterDisplay script executes.
I believe I read somewhere in documentation related to 3.x that some work was done regarding threading, however I can not seem to locate it now.
Am I just (noticing/having to re-code) things I potentially coded incorrectly in previous versions of ITScriptNet, or is there something new I need to be aware of? When I upgraded my 2.4 version of program to 3.1 (for testing purposes at this point), several things have 'broken', and I have had to find significant work arounds and/or have had to completly re-code. Did I miss something in my upgrade process?
Mark Robinson |
|
|
John Lathem
Posts: 78
|
 |
|
Re: AfterDisplay script
Posted: 14 Oct 09 8:27 AM
|
One of the changes between 2.x and 3.x is the way prompts are initialized. In 2.x, you could see some delay as controls were created during the prompt setup process. In order to smooth the transition from prompt to prompt, we now create all of the controls Hidden, then show them all at once. This happens just before the AfterDisplay script runs.
What's probably happening is that the controls have not had time to actually paint themselves when you AfterDisplay script runs. This might also be the cause of the other issue you reported with the progress message not appearing during your prompt setup. However, the AfterDisplay script should be able to rely on states such as enabled/disabled, visible/hidden, control values, etc, as the controls have been created and initialized.
The script engine was also rewritten from 2.x to 3.x. We intended to keep backwards compatibility as much as possible between the versions, however there are some differences that have shown up.
In our efforts to improve ITScriptNet, we are interested in hearing about items that don't work the same way in 3.x as they did in 2.x. Please continue to let us know, either by posting here or by emailing them to support@z-space.com. |
|
|
|
Re: AfterDisplay script
Posted: 14 Oct 09 1:30 PM
|
I have noticed the new behavior. However, what seems to occur is the AfterDisplay script is executing to completion, or near completion, before any of the elements paint. Thus the user sees their current prompt for an extended period, making it appear to them they did not 'click the button' or the device may have suddenly locked up.
In v2.4, even though the elements on the screen would not paint simultaneously, the user did get an indication something was happening while the screen 'morphed' into the next prompt. I am not stating that was better, just something I relied on to help users know what is going on.
What I have gone to is inserting another prompt ahead of the actual next prompt with its only purpose to display a different screen to the user with my progress message. Where I used to do something like GoToPrompt("UserInfoNextPrompt", FALSE) from an On Click or Next Prompt script, I now do GoToPrompt("PreUserInfoNextPrompt", FALSE) which displays the message instantaneously, and PreUserInfoNextPrompt performs the original GoToPrompt("UserInfoNextPrompt", FALSE) from its AfterDisplay script. The PreUserInfoNextPrompt and UserInfoNextPrompt have identical user messages, so the user sees the same progress message until UserInfoNextPrompt actually goes to its next prompt. Makes the program larger due to adding more prompts, but works.
Mark Robinson |
|
|
|
|