asked on

InstallShield 2009 Premier: How to create a text box validator

Product: InstallShield 2009 Premier
Package Type: Basic MSI

I need to validate a text box entry to ensure It is not empty or contain any non-alphanumeric characters.

My question is what are the steps for adding textbox validation with InstallShield 2009?

Thanks,

rick

ASKER CERTIFIED SOLUTION

Vadim Rapp

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

sadlermd

ASKER

thanks, i will give this a try

sadlermd

ASKER

This solves 99% of the problem - the issue now is how to make the "Invalid Input" message display.

Here is the sequence:

1. user enter an invalid value
2. user clicks "Next"
3. the validation occurs and prevents the user from proceeding to next page
4. the "Invalid Input" text does not appear

Here is a snippet from the log - I am validating that the name doesn't contain non-alphanumeric characters:

Action 12:17:25: MFSServerAccessInformation. Dialog created
MSI (c) (BC:30) [12:17:29:441]: PROPERTY CHANGE: Modifying MFS_NAME property. Its current value is 'NewYorkOffice'. Its new value: 'New York Office'.
MSI (c) (BC:30) [12:17:29:601]: Doing action: caVerifyAlphaNumericTextOnly
Action 12:17:29: caVerifyAlphaNumericTextOnly.
Action start 12:17:29: caVerifyAlphaNumericTextOnly.
MSI (c) (BC:A8) [12:17:29:603]: Invoking remote custom action. DLL: C:\Users\RICK~1\AppData\Local\Temp\MSIA626.tmp, Entrypoint: m1
MSI (c) (BC:04) [12:17:29:656]: PROPERTY CHANGE: Modifying ALPHA_NUMERIC_TEXT_ONLY property. Its current value is '1'. Its new value: '0'.
Action ended 12:17:29: caVerifyAlphaNumericTextOnly. Return value 1.

Note that if i click the "Back" button and then click "Next" to return to the page i'm validating, the "Invalid Input" is visible.

It seems like the Dialog Behavior "Subscriptions" page contains the answer but i'm not sure.

Thanks

rick

Vadim Rapp

You are right, when property is set from within custom action, this does not cause the controls on the dialog to re-evaluate the conditions. They do it when a property is set by Installer itself, or when you re-display the dialog like you did.

To work around this problem, we can create fake property change: set another event for the Next button:

event: [dummy]
argument: dummy
condition: 1

Now Installer will see that some property might have changed, and will force the controls to re-evaluate the conditions, so the label will react.

Subscriptions that you mentioned would be logical choice, if only the event "some property was changed somewhere" was available to subscribe to; but it's not.