Use a system value as default for textbox?

[dandy-72]

Hi all,

I've figured out how to prompt a user for a value for a custom environment variable through a textbox, and have it set during installation. Essentially, if a text box in a custom dialog box is named txtUserProvidedEnvVarValue, then under System Changes/Environment, I have an entry with "Name" set to the name of the environment variable to be defined, and "Value" set to "[txtUserProvidedEnvVarValue]". That works great.

In the dialog box, I'm assigning a fixed/hardcoded default value (under Property / Default Value after selecting the text box) so the user has a sample he can work with (and often, the user can just keep the default value suggested). However, **if** the environment variable already exists when the installer is run (or re-run), I'd like to pre-fill the default value in the textbox with the value of the existing environment variable instead of the hardcoded one - because it's already been set, and it should take precedence over the default value I might otherwise suggest.

Similarly, I have another dialog box that prompts the user for a port number to open in the Windows firewall (with a default of 5000). In this case, the Port value (under System Changes/Windows Firewall/Exceptions) is set to [txtUserProvidedPortValue]. Easy enough. However, if the port has already been opened (there's already an Inbound Rule with the Display Name I use in the installer), I'd like to pre-fill the textbox with the port number that the user had supplied when the installer was run the first time around (or else, keep my default).

How do I go about telling the respective text boxes to use these values if they already exist on a system?

Thanks
- Dan

[Catalin]

Hello Dan and welcome to Advanced Installer forums,

Thank you for the detailed explanation.

At a first glance, I would suggest using a public property (only uppercase letters --> e.g. TXT_USER_PROVIDED_ENV_VAR_VALUE) instead of a private one (like the one you used). For a better overview about the differences between those two, please have a look over our "Windows Installer Properties" article.

If you have any questions regarding this, please let me know and I will be glad to assist.

However, **if** the environment variable already exists when the installer is run (or re-run), I'd like to pre-fill the default value in the textbox with the value of the existing environment variable instead of the hardcoded one - because it's already been set, and it should take precedence over the default value I might otherwise suggest.

Here, we are talking about two different scenarios:

1. The installer is run for the first time (and the value is written by the user at install time) ==> we want to preserve this value when the setup is re-run (during an upgrade).

This can be done through our support for "Persistent Properties". For more information about this, please have a look over the following article:

How do I make the properties in the package keep their values during Maintenance or Upgrade?

This way, during an upgrade, the setup package will know the value that was entered by the user at the first-time install.

2. The installer is run for the first time, but somehow the value of the system variable is already present on the machine.

To be fully honest with you, I doubt this is highly likely to happen.

However, in case this is happening, there are two things we can do:

• Create a "Search" for that value and then perform a "Set Installer Property" custom action that will set the value of your property to the value of the search

• If this is not possible through our support for searches, then another approach would be a custom action that looks for the value and then sets the property accordingly. For more information about this, please check our "How to set a property using Custom Actions" article.

Hope this helps.

Best regards,
Catalin

[dandy-72]

Hi Catalin, I appreciate the quick response.

This is my first time trying to put together an installer with Advanced Installer, so I wasn't familiar with the idea of persistent properties. Works like a charm! I can see the values being saved in the registry, reloaded on subsequent launches, and removed when you do an uninstall.

Regarding the first-run install--or, what would appear to the installer to be a first-run install, because the user has somehow gone out of his way to get the app removed *but* has left behind customizations - you're right, it's not likely to be a common thing, and if a user goes through that sort of thing, then it's really on him to provide the values back. There's only so far I should go to provide the user with some conveniences. For customers, this should never be a problem; I was really thinking more about internal testing, where my in-house users hack their systems together and don't necessarily go through the "proper" channels to get an app installed or updated. The compromise I've arrived to is plenty good, even for those users.

The only thing I haven't figured out yet is how to make my custom dialog boxes (those prompting for custom values) appear in the right order, when doing Maintenance (only). I'm okay for First Time Install. But under User Interface / Dialogs / MSI Package / Maintenance, I used Add Dialog in Sequence to add my existing dialog boxes (that I had initially defined under First Time Install), but I can only make them appear either as the first ones (even before the initial PrepareDlg), or after the existing VerifyReadyDlg. Ideally, they should be inserted in-between MaintenanceTypeDlg and VerifyReadyDlg. That is, if I right-click on the Maintenance node in the Install Sequence tree and select Add Dialog in Sequence from there, it'll appear as the first one. If I right-click on the MaintenanceTypeDlg node instead to select Add Dialog in Sequence (to get it added immediately after), it appears after VerifyReadyDlg. I can't seem to drag my custom dialogs to the desired location, and the right-click menu for them does not show any sort of Move Up/Move Down or Reorder or Change Sequence option. Ideally, the user would get his Welcome screen, pick the type of maintenance (Modify/Repair/Remove), then get my custom prompts, and finish off with the final Verify. As it stands, the user gets a sequence of dialog/buttons that go Next/Next/Install/Next/Next rather than completing with Install.

[dandy-72]

I hate to respond to my own posts, but here's an important follow-up:

I've found out that if I select Add Dialog, rather than Add Dialog in Sequence, I can get the dialog boxes to appear in the correct order (at least as far as the tree is concerned), but when the installer is actually run, the custom dialog boxes are skipped altogether.

[Catalin]

Hello Dan,

This is my first time trying to put together an installer with Advanced Installer, so I wasn't familiar with the idea of persistent properties. Works like a charm! I can see the values being saved in the registry, reloaded on subsequent launches, and removed when you do an uninstall.

You are always welcome! I am really glad everything works as expected.

Always my pleasure to help.

But under User Interface / Dialogs / MSI Package / Maintenance, I used Add Dialog in Sequence to add my existing dialog boxes (that I had initially defined under First Time Install), but I can only make them appear either as the first ones (even before the initial PrepareDlg), or after the existing VerifyReadyDlg.

As explained in the "Dialogs Page" article:

A dialog sequence refers to a set of dialogs that are displayed during the same Standard Action. For example: WelcomeDlg, FolderDlg, VerifyReadyDlg are all part of the Wizard Dialogs Stage WelcomeDlg Standard Action.

As you can see above, a single action triggers multiple dialogs. With that being said, it is not possible to alter their order (e.g. schedule the dialog that you have added in the sequence before the "VerifyReadyDlg" dialog).

Hope things are a bit more clear now in what regards the dialogs sequence.

I've found out that if I select Add Dialog, rather than Add Dialog in Sequence, I can get the dialog boxes to appear in the correct order (at least as far as the tree is concerned), but when the installer is actually run, the custom dialog boxes are skipped altogether.

Additionally, in the article I've linked above, it also states that:

Dialogs triggered by control events have a lightning symbol on their icon.

If you open your project and go to "Dialogs" page --> "Maintenance" --> "MaintenanceTypeDlg" --> select any button ("Modify", "Repair" or "Remove"), you can notice that the button has a specific event attached to it, as in the following screenshot:

EventDlg.png (170.26 KiB) Viewed 3505 times

If you double click on the event, you will notice that it is not possible to change it:

EventVerifyRemoveDlg.png (166.43 KiB) Viewed 3505 times

The reason behind this is explained above. Basically, since all these dialogs are in sequence and they are part of the same action (the same action triggers them), their order can not be altered.

Hope this information helps.

Best regards,
Catalin

[dandy-72]

Hi again Catalin,

Apologies for the delay in responding - priority changes...need I say more? I finally got a bit of breathing room, so I thought I'd check up on this. Thanks for the follow-up.

So now I think I understand the *why*, but I still don't understand the *how* I can then make it work. I'm sure Advanced Installer has the flexibility.

I'll dig into the pages you've linked to - I'm sure the solution is in there somewhere...

Thanks again for the response.

[Catalin]

Hello Dan,

No worries about the delayed reply.

So now I think I understand the *why*, but I still don't understand the *how* I can then make it work.

Unfortunately, the "why" here pretty much explains that this scenario is not really achievable.

I'm sure Advanced Installer has the flexibility.

Since Advanced Installer is built on the Windows Installer technology, there are some things that are not customizable. This is one of them.

As I have explained above:

A dialog sequence refers to a set of dialogs that are displayed during the same Standard Action. For example: WelcomeDlg, FolderDlg, VerifyReadyDlg are all part of the Wizard Dialogs Stage WelcomeDlg Standard Action.

As you can see above, I have mentioned the "WelcomeDlg Standard Action".

As it is stated in the "Standard Actions" article:

A standard action encapsulates a typical function performed during the installation or maintenance of an application. Windows Installer has many built-in standard actions.

More information about this can also be found in the "Suggested InstallUISequence" article, where you can notice the standard action we have earlier mentioned.

In our case, most of the dialogs from the "Maintenance" are triggered by a single action - "MaintenanceWelcomeDlg":

• MaintenanceTypeDlg - based on which another dialogs are triggered:

• VerifyRepairDlg - if "Repair" option is selected

• VerifyRemoveDlg - if "Remove" option is selected

• CustopmizeDlg - if "Modify" option is selected

The ability to spawn another dialog is possible due to another action we schedule. This can be seen in the "Table Editor" page --> "InstallUISequence" table. Basically, here we have multiple actions that executes in a specified order. Let's consider the following example for (I'd say) a better understanding:

Action_1_thatSpawnsADialog
MaintenanceWelcomeDlg
Action_2_thatSPawnsADialog

In the above scenario, the first action executes ==> it spawns a dialog

Then the second action executes ==> it spawns multiple dialogs

Then the third action executes ==> which spawns another dialog

Here, unfortunately, we can not interfere with the order of the dialogs spawned by the second action, because, well, they are all spawned by the same action. The only order we can modify is the order of the actions.

We can, for instance, schedule "Action_2" to execute before "MaintenanceWelcomeDlg" and "Action_1" to execute after, but that's pretty much it.

Hopefully things are more clear now on why this scenario is, unfortunately, not achievable.

Best regards,
Catalin