11 replies to this topic

[levi]

Hi All,
I am using Installshiled develper 7.01
I created a basic MSI project. I then created a Custom dialog box with few edit boxes. I was able to display the dialog box. (i added it in the sequence/action).
How do I validate the values i enter into the edit box of this dialog

Regards,
Levi

[Silverlay]

The only way i know to validate values of editboxes is to write InstallScript function that will drop messagebox if value is wrong ...
Try to use masked edit (with templates)

[Stefan Krueger]

Using a custom action thate xecutes on the Next button of the dialog. This custom action could be a DLL function, or a script (VBScript for instance)

[levi]

Thanks Guys
I was able to make some checks...

Levi

[sasquatchan]

I've got a custom action that validates the user input. So I can catch if the user entered somethng invalid, say, alpha chars when the input should be numerical only (Bummer that the numerical only propetry cannot be applied to edit boxes -- help says the property is only available if you want to export the dialog to an .rc file ... )

But what I want to then do is re-set the invalid data to the default..

The edit box is tied to a property, so that's how I read it in my DLL (MsiGetProperty()). So when I've found it is invalid, I set that perperty (MsiSetProperty()) to the default value and display an error message (in my DLL, simple message box) to tell the user what input was invalid. The user "OK"'s the message box, but the dialog doesn't refresh to show the restored-to-default value that I just changed. If the do a back->next button, the dialog correctly refreshes with the changed value.

Does anyone know how can I do that programatically ?

[Stefan Krueger]

Use a MaskedEdit control instead of a regular Edit control to make sure they only enter numbers.

[sasquatchan]

I've played around with the masked edit, and that does work for allowing only numbers, but in this case, we're looking for a port. (And a password as well, that's a normal edit box with the password attribute set). So there's various "rules" to validate what is an acceptable port and what is not, and the password/re-enter the password must also match.

I fill the port box with our default, and the password/confirm edits are empty. When we validate (when "next" is hit), I want to make sure the passwords match, and the port is valid (1025-64k) and not bound by any other process. All that code is there, working. But, if the user, say, entered two different passwords, I want to zero back out that edit box, or if they entered a port in use, I want to restore the default.

The user will get a popup saying what's wrong, but if I reset the control's property, it isn't reflected in the dialog (like wiping out the passwords if they don't match, or reverting to the default port if an invalid port is entered, etc). That's what I'd like to accomplish. Any ideas on it ?

[Stefan Krueger]

Create a copy of the dialog and switch between the "twins" using the Next button. This will essentially reload the dialog, thus updating all edit boxes.

[DK_TW]

I've solved the same problem by placing "EndDialog" event with "Retry" argument around the call to function that performs validation.

But, there's another problem I've encountered: VB script custom actions run fine when I call them via "DoAction" event for the "Next" button. BUT, InstallScript custom actions just hang up the engine: installer shows hourglasses and never gets back to work. In log, there's a record
Action start 15:50:46: ISCheckUserInput
and it's the last record.

Could someone help me with this problem?

P.S. I'm using web project in IS DevStudio 9.

[Stefan Krueger]

Looks like a known problem:

Setup Hangs During MSI API Call
Description:
In a Basic MSI project when calling certain MSI API functions (like MsiSetTargetPath or MsiSetFeatureState) in a InstallScript custom action that is launched via DoAction from a dialog button you setup will wait indefinitely. It will not display an error message or crash, it will just not do anything anymore until you end it in task manager.
Cause:
This happens because of an apparent design decision in MSI. When DoAction is called, it appears that MSI does not process Windows messages. InstallScript uses COM to call MsiSetTarget, and thus relies on the Windows message queue. Hence the deadlock occurs, which does not occur in a C++ custom action that does not use COM.
Workaround:
Do not to call these MSI APIs from InstallScript if they are fired from DoAction from a dialog button. Insert the custom action into the sequence or use a DLL instead of InstallScript. (You can even create a custom action of type Standard DLL to call the function in msi.dll directly). Or convert your project to a Standard project and call the function from an event handler in your script.
Status:
InstallShield confirmed that this is a problem in all versions of InstallShield Developer and in ISWI since version 1.52.
Created: 2002-09-06

http://www.installsi...bugs_isd802.htm

[DK_TW]

But there are only two calls in my IScript custom action: MsiGetProperty() and SprintfMsiLog(). Do they appear on the black-list? BTW, where can I see the list of functions that cannot be used in CA called from dialogs?

And how exactly can I "use a DLL instead of InstallScript"? Are there any examples of such adaptation?

[Stefan Krueger]

There is no comprehensive black list.

Custom Action DLL sample:
http://codeproject.c...ustomaction.asp