PDA

View Full Version : Globalising SdAskOptions



dbriggs
09-24-2003, 09:04 AM
I have been using SdAskOptions for ever to collect user-defined configuration settings. Now, it occurs to me that my pre-packaged SETUP.ISS response file contents are going to be in one language. If a user tries to run my Setup silently, but the system language is different to mine, my responses won't match the options that were offered.

Is there any way around this apart from creating more data sets at build time? I want to be able to define the options at run-time but there seems to be no way to give them a language-independent name.

It may not matter that my responses do not match any of the options that are offered. I'm guessing that my default settings will not be changed, but that probably isn't reliable enough.

One possibility would be to use a dialog like SdOptionsButtons, but that only has room for four buttons and I need more than that.

Any ideas?

Thanks for any suggestions,

David

DevinEllingson
09-24-2003, 06:41 PM
dbriggs,

The best way to handle this problem is to "remove" the SdAskOptionsList dialog from the silent install scenario, instead just update the settings manually based on whatever they should be (i.e.)

[code]
if( MODE = SILENTMODE || MODE = RECORDMODE ) then

Option1 = 1;
Option2 = 2;

else
SdAskOptions( ... )

endif;

Using this method you don't need anything in the response file for your SdAskOptions dialog since when the setup is running silently the dialog is skipped.

Devin Ellingson
InstallShield Software Corporation

dbriggs
09-25-2003, 07:35 AM
I understand, but that also means that the end user has no way to change the settings from whatever I define. I don't want to do that. What I need is a way to make SdAskOptions language-independent, like the main component, sorry feature, selection dialogs.

It occurs to me that I could create the feature list using String IDs instead of the actual strings. I would have to change the dialog code to pick up and display the strings, rather than the IDs. The response file would also have to contain the IDs, but so long as the equivalence was not lost, that might work...

What do you think?

David

DevinEllingson
09-25-2003, 02:45 PM
dbriggs,

So are you saying that you want the end-user to be able to customize the .iss file to customize your setup?

Devin Ellingson
InstallShield Software Corporation

dbriggs
09-25-2003, 03:24 PM
If my end-users cannot use a sample .ISS file that I have provided because mine is in English and they are French, then they would have to record a new install in their own language. The problem disappears at that point, but I haven't done as much as I would like to help them.

In the case of a "standard" silent install of my Client programs, for example, I would have to ship pre-recorded response files in all languages and select which one to use at some point. Most of the install is already language independent, so why not more?

I have been looking at the FeatureSetItem (sp?) function, and that seems to provide a display string for a feature in a script-generated media set. If I pass the IDs rather than the localised names, change the code for SdAskOptions to check whether the String Table contains such a String for each item, I could keep the actual selections language-independent. They would just *look* language-dependent. I don't know if this would work, but it seems simple enough to try. This strategy would not interfere with the normal use of SdAskOptions, where Strings and not IDs are used.

Does that sound like a plan?

David

DevinEllingson
09-25-2003, 07:36 PM
dbriggs,

I know enough about your specific problem to determine whether what you describe above will work.

Typically in a silent install the user doesn't get to make any choices, the choices are determined by external factors such as the .iss file or by the language the setup runs in, determined from the OS.

What I would do is in the silent case is skip the dialog altogher and base the results on however the defaults for the dialog are set. (i.e.) typically SELECTED_LANGUAGE, but it depends on how you wrote your setup.

If you want the user to be able to control this directly I would recommend creating your own response file using the .ini file format and just read/write the information directly using the profile API's, and then just document to your users how to modify this file.

Devin Ellingson
InstallShield Software Corporation

dbriggs
09-26-2003, 03:03 AM
Thanks for the comments.

Are you saying that the Feature display item does not replace the Feature name in an SdAskOptions dialog with a script-generated media set? I haven't tried this yet, so I don't know. It won't take long to test, but I'm at home right now and my licence doesn't allow me to run DevStudio here.

Unfortunately, skipping the dialog doesn't help with my approach to dealing with the unpredictability of the generalised silent install. This is changing the subject slightly, but I have put, would you believe, an SdAskOptions dialog into OnShowUI so that the response file can force Setup to go through "First time install", "Maintenance Mode", or "Update Mode" paths. Disabling the dialog in this case leaves me back where I was, in other words, not knowing whether the current product and version is already installed *before* the SETUP.EXE -s /f1 command is executed. This is my considered solution.

I could disable some or all dialogs in a silent install, but then why use a product like DevStudio to put up a user interface?

David

dbriggs
09-26-2003, 07:48 AM
A quick note to say that I have created a wrapper function for FeatureAddItem that takes the feature's String ID instead of the normal descriptive text. The wrapper adds the item using the normal FeatureAddItem call and then looks for the String in the String Table using the LoadStringFromStringTable function that was introduced in Pro-6 or 7? If this function finds a String, a second call is made using:-

FeatureSetData (szMedia, szID, FEATURE_FIELD_DISPLAYNAME, 0, szDisplayName);

The String Table entry is displayed in SdAskOptions, but the String ID is recorded in the response file. A perfect solution!

David

dbriggs
02-23-2004, 02:35 PM
Unfortunately, this seems to have been broken by SP-1.

To recap, I am using the SdAskOptions dialog as the first dialog in a silent/record mode Setup to display a script-created component set, where the options are: First Time Install, Maintenance Mode, and Update Mode. I am using String IDs rather than plain strings, and looking up the localised display names in the String Table at run-time. This was working nicely when I finished it in September.

Record mode runs correctly, and the correct String ID is saved in the response file (e.g. remove.iss). However, in a silent mode install, the first option (=first time install) always seems to be selected, regardless of what is in the response file. That is, the first if (FeatureIsItemSelected ()) comes back TRUE, even when it shouldn't.

I have made a copy of SdAskOptionsDlg.rul and disabled the display name lookup code in my _FeatureAddItem function in silent mode, but this isn't helping. I can't see what is wrong. My SdAskOptions returns a component set, but that looks like an empty string in the debugger.

The one hint I can see in the Help is that maybe I should be calling SdSetupType before SdAskOptions. I would normally do that afterwards, in a first time install, and this is a script-created component set, so maybe it's not necessary?

Any ideas?

David

dbriggs
02-24-2004, 10:34 AM
I have copied some code fro SdAskOptionsDlg.rul to walk through the components in my script-generated set and check the settings. Before I call SdAskOptions in silent install mode, the first (default) option is selected. Afterwards, both the first and the second are selected. This is SdAskOptions (... EXCLUSIVE), of course. It looks like there is a bug in SilentReadComponent or ComponentSelectItem.

Again, record mode works correctly, but silent mode does not.

David