This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: How to Disable buttons in InstallScript MSI projects?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 06, 2007
01:34 PM
How to Disable buttons in InstallScript MSI projects?
Project Type: InstallScript MSI
Requirement: When user selects a radio button gray out (disable) other buttons of form until user reselect that radio button.
Since in this project type there isn’t “conditions”, so I’ve been trying to use Disable() and Enable() but I realized that it takes affect on the next opened dialog and can’t be used to on the current dialog. So, any suggestions what to try next?
Requirement: When user selects a radio button gray out (disable) other buttons of form until user reselect that radio button.
Since in this project type there isn’t “conditions”, so I’ve been trying to use Disable() and Enable() but I realized that it takes affect on the next opened dialog and can’t be used to on the current dialog. So, any suggestions what to try next?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 06, 2007
04:26 PM
I believe there's an EnableWindow API function that can be of use; you might look at the source for the SdLicense2 dialog box, which does something similar to what you describe.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 07, 2007
01:46 PM
Hi
The Windows API call EnableWindow() didnt work for me, but I did find an API call that did; _WinSubEnableControl();
Just in case some1 else needs to use this you have to pass it a handle to the form, the ID of the control and 0 (enable) or 1 (disable)
eg: _WinSubEnableControl(hwndDlg, RES_PBUT_NEXT, 1);
to get the dialog handle use: CmdGetHwndDlg(DialogName). You have to call it after WaitOnDialog(). I call it in the DLG_INIT section of the dialog loop/switch.
Its too bad that with every project type you're forced to use differenet methods enable and disable functionality (API calls, conditions, etc.). I wonder where can I put in an enhancement request to have all funcationality available in all projects types?
The Windows API call EnableWindow() didnt work for me, but I did find an API call that did; _WinSubEnableControl();
Just in case some1 else needs to use this you have to pass it a handle to the form, the ID of the control and 0 (enable) or 1 (disable)
eg: _WinSubEnableControl(hwndDlg, RES_PBUT_NEXT, 1);
to get the dialog handle use: CmdGetHwndDlg(DialogName). You have to call it after WaitOnDialog(). I call it in the DLG_INIT section of the dialog loop/switch.
Its too bad that with every project type you're forced to use differenet methods enable and disable functionality (API calls, conditions, etc.). I wonder where can I put in an enhancement request to have all funcationality available in all projects types?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 07, 2007
03:51 PM
I believe the official channel for feature requests and other product feedback is here: www.installshield.com/feedback.
The issue in this case is that the two underlying technologies are so different: InstallScript using a code-driven, Windows-resource-and-API foundation (with a long history), and MSI using a database-table-driven architecture (approaching its tenth birthday, come to think of it). So while it's conceivable to create (and would nice to have) an environment that abstracts the two types and generates one or the other type of installer based on that, those days are probably a while off.
The issue in this case is that the two underlying technologies are so different: InstallScript using a code-driven, Windows-resource-and-API foundation (with a long history), and MSI using a database-table-driven architecture (approaching its tenth birthday, come to think of it). So while it's conceivable to create (and would nice to have) an environment that abstracts the two types and generates one or the other type of installer based on that, those days are probably a while off.