I'm just wondering if someone could comment on my use of the native engine. First, the background: my package installs an ini file which I stamped as permanent. For that reason, the file survives when I uninstall the package. All well so far. When I install the package, if the file exists I read it with the Get Ini command and I get a value back which I present in a dialog so that it's value can be edited. I then later run the Apply Install command and that creates the file if it's not there. After Apply Install returns I then execute Edit Ini File and write the (possibly) edited value back to the file.
Edit Ini File is a purple command. Having run Apply Install once to create the file if it doesn't exist, should I run Apply Install a second time after I execute Edit Ini File? I can't remember if executing Apply Install clears down the cached list of commands when it's finished?
What I did after Apply Install returns successfully is to switch into native engine mode and then execute Edit Ini File. The file is then updated and all works fine. Clearly, I've found a good use for using the native engine as it removes the uncertainty I have about what happens if I were to run two Apply Installs. Another part of me thinks I should have put the Edit Ini File immediately before the Apply Install as in theory it should be the last command to be executed? That is, the file is installed earlier in the sequence so when Edit Ini File is executed the file has now been installed. Does it work like that in practice? Perhaps I did not need the native engine but it was quite clear that it would do what I needed. I'm not sure though if I really need to use it the way I did? Comments appreciated.
Native engine feedback.
Native engine feedback.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
Re: Native engine feedback.
Hey Peter!
In general, it is not recommended to run more that one Apply Install commands. In fact, there isn't really a need to.
In your example, the best approach would be to use the Native Engine throughout - that way, commands get executed immediately. Is that am option for you?
Thanks!
In general, it is not recommended to run more that one Apply Install commands. In fact, there isn't really a need to.
In your example, the best approach would be to use the Native Engine throughout - that way, commands get executed immediately. Is that am option for you?
Thanks!
Aviv Giladi
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
Re: Native engine feedback.
Aviv, native engine mode is certainly an option. It got me thinking that if for example you set it at the top of the script and you later need to Terminate Installation for some reason or another what happens to everything upto that point? How would you "know" what was applied and back-out the changes? I've not used transactions in a script yet but if I were in native mode and a script needs to abort would the native mode rollback transactions up that point? Or would I need to use 11's restore point paradigm?
What my installation needs to do works ok as I never need to delete the file or overwrite it if it exists so transactions and restore points are not needed in my case. I would like to know a good practice strategy where far more involved scripts are required.
What my installation needs to do works ok as I never need to delete the file or overwrite it if it exists so transactions and restore points are not needed in my case. I would like to know a good practice strategy where far more involved scripts are required.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
Re: Native engine feedback.
Hey,
Actually, all you have to do is set the NATIVE_ROLLBACK variable to TRUE (or make sure its set to TRUE).
In this case, all changes will be rolled back when cancelled just like with the Windows Installer engine!
Actually, all you have to do is set the NATIVE_ROLLBACK variable to TRUE (or make sure its set to TRUE).
In this case, all changes will be rolled back when cancelled just like with the Windows Installer engine!
Aviv Giladi
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
Re: Native engine feedback.
Doh! How stupid was I to think that IA would not have thought about that. 
Methinks I have to read up the predefined variables again and this time, hope some of the knowledge sticks.
Methinks I have to read up the predefined variables again and this time, hope some of the knowledge sticks.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
Re: Native engine feedback.
Hahaha its okay - there is a lot to learn about IA! Good luck.
Aviv Giladi
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Product Guides - http://www.installaware.com/publication ... guides.htm
InstallAware Help -F1 anywhere in the InstallAware IDE

