How can I abort a Windows Installer using VB Script that when it choose a certain option, the installer will force end?
I am using Visual Studio 2010 Setup Project:
Here is the pseudocode for it:
MSGBOX "Do you want to continue installing?"
IF Press YES { Continue Installing }
If Press NO { Abort/Exit the installation process. }
End
I expect this final window to appear after I press NO:
It might help if you said something about what the incorrect option is. It might be something in a dialog (like TextBoxes) that you've added to the UI and you can't validate it because VS setups have no support for custom actions to run during the UI to validate entered data.
Either way, all custom actions in VS setups run after all the files are installed and the setup is virtually complete. In other words the only place to validate your data is after the install has finished when it's too late to stop the installation. All you can do is return an error from the VB Script and have the whole setup abort and roll back, and I don't think that's what you want.
If you really need this kind of functionality you need a tool that has support for it, somewhere in the dozens of tools that can create MSI files.
In a more functional tool I don't think you'd use a dialog choice like that. The dialog that offered the choice would have a custom action validate the data when the Next button is clicked. If the data is incorrect then the Next button stays disabled. If it is potentially incorrect a warning can appear on the dialog, but there is a Cancel-type button on every install dialog I've seen, so you don't need to abort anything - tell the user to cancel. But most dialogs have a back button to go back and change data too. In other words your UI flow isn't typical of most wizard-type flows in installs and therefore could be confusing.
Related
I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.
I want make my MSI installer to display nothing when I double click on it. Currently it displays the simple default progress bar during installation. I don't even want that to display. Is there any work around for this?
No, Windows Installer will show a basic UI if you don't provide one. Some form of feedback is required, else how would the user know they successfully launched the package?
We have an installer wizard (written in .NET) which configures and kicks off a series of standard Windows installers. The installers are run silently. Right now, clicking "Cancel" on the wizard's dialog stops further installers from running, but does not stop whatever installer is running silently in the background.
Is there a way to send a installer running silently the equivalent of pressing the Cancel button on a non-silent install? (I could kill the installer process, but I expect that that will leave a half-installed (and probably non-uninstallable) mess behind.)
I'm not sure if you're creating new instances of these installers within your own installation wizard so I don't know how applicable this solution is going to be, but if you do have access to the actual (derived) System.Installer objects that correspond to the installers, calling the overridden System.Installer.Rollback() method of those objects should achieve the desired result. Let me know if this doesn't work and I can try helping you further.
Background:
Currently, we have created a wizard by WiX UI. The user should click next, next and next...
But suddenly, we found that there's nothing should be interacted with user, user just need keep clicking next. So..
Here is the desired behavior:
We automatically switch to the next dialog page after all the stuff (such as pre-check and so on) done in the current page. Once there are errors in installation process, we show the error page to the user. That makes for a streamlined installer experience for the user. One click, everything done.
Can WIX do this kind of stuff purely, or should I need some other work to do to implement this?
No, you'll need to define your own external UI handler (like the MS Office installer does) if you want something "fancy" - why not just remove the UI altogether? We do this for a number of setups....
Take a look at WixUI_Mondo, WixUI_Minimal and other predefined UIs that come with WiX. Otherwise you can define your own dialogs and their sequence.
You can try with Wix_minimal or you can go for your own customized dialog boxes.
You can also customize the sequences of the dialog boxes by your own need. I suggest you to do the second option.
Is it possible to create shortcuts in Install Shield 2009 based on user input?
In essnes, a shortcut will be created (on the desktop) only if the user (who runs the installation) wants to do so
We have a screen that prompts the user to create desktop and quicklaunch shortcuts.
The shortcuts are then each in individual components with a condition set to only install if the checkbox was selected.
You also should store this response in the registry somewhere, and read it back during a reconfigure, upgrade, repair, etc. Otherwise if the checkboxes were on by default and that screen does not display to the user, the condition will evaluate to true (because the default property is true) and although the shortcut was not initially installed, it will be created during the repair if the components condition is reevaluated.
I do something similar to Sacha, but I'm lazier. ;-)
I create a component for each desktop shortcut (I hate software that assumes it's allowed to dump shortcuts on my desktop); no file in the component. Then I assign each of these components to its own feature. Then I can use standard feature selection dialogs (which is built in automatically and used when the user selects a Custom installation) to let the user select the desktop shortcut features.
I don't see a lot of software installers offering to install optional shortcuts in the feature selection dialog, but it strikes me as a natural place to do it. More technical users may see this as mixing metaphors.
FWIW, I originally did this in an InstallScript/MSI project, and I've just done the exact same thing in a straight MSI project, and the technique works fine in both.
It's been a while since I've used installshield, my company is currently using WISE as an installer; however, it should be possible to do what you are asking.
In general installer terms you need to do the following:
Make a screen for your installer that presents the option to create the shortcut, this screen should have the prompt text and a checkbox.
There should be a mechanism for storing the response of the checkbox in an Installshield property.
During the execution phase, use the reponse to trigger the creation of the shortcut.
I don't know about the capabilities of Installshield 2009 for whether this can be done without editing the script itself.
I hope this helps.