1. Don't think so. 2. Not sure.
3. Not sure it can participate in rollback. 4. I don't know if the Windows Installer cares. Note: I didn't read the MSI SDK closely so you'll probably get more specific answers there. -----Original Message----- From: Karl Denning [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2008 11:54 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding buttons to the ProgressDlg I'm on the verge of trying that. async + wait for return code looks like the type I should use. I've been digging around MSDN, but cannot find info... Rob - could you answer some general Qs regarding async CAs? 1. Does WI display the ProgressDlg until all async CAs have finished? 2. What happens to async CAs if the user cancels installation after the async CA has been launched? 3. My CA doesn't generate new files, (so I don't think a rollback is required to mop up), but if one was needed, when should it be sequenced? 4. How does WI behave if an async CA returns a fail (or cancel) return code? - Should async only be used for CAs when you don't need to care if the CA fails? Thanks Karl Async CustomAction? -----Original Message----- From: Karl Denning [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2008 10:29 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding buttons to the ProgressDlg Sorry - I was trying to reduce the task to a minimal sentence because the big picture is fairly complicated, and I think will turn off most people. Here goes.... The application relies on a database, which is unique per installation. The database, although is not very large, takes 2-5minutes to build. The database must exist before the application is executed. The database _does_not_ need to be complete before the application is executed. The more populated the database is, the faster the application will perform. The user should be given the ability to stop the CA that is generating the database. Stopping the CA must not cause a rollback (it is not the same as 'Cancel'). >From a usability perspective (perceived performance), it is preferential to do the table crunching in the installer, than to offload it to the application startup. Assumption: people don't mind waiting for an installation to complete, but they do mind waiting for an application to start. It's a user facing application, so must not look like a hack. Is there a way to improve this design pattern? (I'm trying to avoid writing a custom ui handler if I can) Karl -- View this message in context: http://n2.nabble.com/Adding-buttons-to-the-ProgressDlg-tp1519858p1520381.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
