This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Deferred mode execution
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 09, 2007
04:18 AM
Deferred mode execution
Hi,
I implemented to validate installer script functions using ICE concept. It is by defeault runs in immediate mode. Can any one tell me how I can run it in deferred mode?
Thanks
Hareendra
I implemented to validate installer script functions using ICE concept. It is by defeault runs in immediate mode. Can any one tell me how I can run it in deferred mode?
Thanks
Hareendra
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 09, 2007
10:05 AM
I don't believe the ICE model can really run in deferred mode. As it's supposed to just be validating table (and perhaps file) data read-only, this is not usually a problem. What are you trying to do that needs to be run deferred?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 10, 2007
06:43 AM
Thanks for the information.
In deferred mode almost all system global variables are not maintained. For example, WINSYSDIR global variable is set to the location of\system32 folder in immediate mode; however this variable is empty in deferred mode. And therefore, InstallScript code (production code) has DE_WINSYSDIR global variable which has the value of \system32 folder location in deferred mode. We introduced another DE_WINSYSDIR global variable specifically to emphasize that in deferred mode WINSYSDIR is not maintained anymore and something should be done to get the value of this variable.
Unit Test Suite should test functions in their modes. If a function is used in immediate mode, the correspondent test function should also be run in immediate mode. If a function is used in deferred mode, the correspondent test function should also be run in deferred mode. Otherwise many deferred mode related bugs can be missed in the test suite.
Hope that this is clear.
Thanks
Hareendra
In deferred mode almost all system global variables are not maintained. For example, WINSYSDIR global variable is set to the location of
Unit Test Suite should test functions in their modes. If a function is used in immediate mode, the correspondent test function should also be run in immediate mode. If a function is used in deferred mode, the correspondent test function should also be run in deferred mode. Otherwise many deferred mode related bugs can be missed in the test suite.
Hope that this is clear.
Thanks
Hareendra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 10, 2007
09:22 AM
I don't think there's a perfect answer to this one. A good start may be to try to share your setup.rul across multiple projects so you can build a test project using the code you want to test as well as the code that tests it. This test project can then be installed (in order to run test actions in deferred mode), and all that remains is how to access and report the data which indicates a test has passed.
One might argue that this is more of a regression test than a unit test, but once a test relies on the real environment provided to a deferred action, it's already started to blur or cross that boundary anyway.
One might argue that this is more of a regression test than a unit test, but once a test relies on the real environment provided to a deferred action, it's already started to blur or cross that boundary anyway.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)