1
votes

I have an Inno Setup script that I have been using successfully for nearly a year. I am trying to include language support for Japanese, but I am encountering a problem.

My original script (English only) works just fine, even on the Japanese versions of Windows 7. When I include a [Languages] section in my script, with a choice of English or Japanese, items that are supposed to be written to the registry that include the {userdocs} constant are quietly skipped. Files to be installed that include {userdocs} in the installation path are also skipped, yet Inno-Setup gives no messages.

Here is some relevant code from my installer:

Source: "C:\Users\Anon\Documents\Visual Studio 2010\Projects\Myprog\Release\Myprog.exe"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.MFC\mfc100.dll"; DestDir: "{app}";
Source: "C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.MFC\mfc100u.dll"; DestDir: "{app}";
Source: "C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.CRT\msvcr100.dll"; DestDir: "{app}";
Source: "C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.CRT\msvcp100.dll"; DestDir: "{app}";
Source: "Myprog.pdf"; DestDir: "{userdocs}\Myprog\Docs";
Source: "Myprog(Japanese).pdf"; DestDir: "{userdocs}\Myprog\Docs";
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

//[Languages]
//Name: "english"; MessagesFile: "compiler:Default.isl"
//Name: "japanese"; MessagesFile: "compiler:Languages\Japanese.isl"

Root: HKLM; Subkey: "Software\MyCompany\Myprog\V4"; ValueType: string; ValueName: "Docpath"; ValueData: "{userdocs}\Myprog\Docs"; Permissions : users-modify; Flags: uninsdeletekey
Root: HKLM; Subkey: "Software\MyCompany\Myprog\V4"; ValueType: string; ValueName: "Regpath"; ValueData: "{userdocs}\Myprog"; Permissions : users-modify; Flags: uninsdeletekey
Root: HKLM; Subkey: "Software\MyCompany\Myprog"; ValueType: string; ValueName: "Serial"; ValueData: "{userinfoserial}"; Permissions : users-read; Flags: uninsdeletekey

If I leave the [Languages] section commented out as it is shown here, the installer works fine on Windows, when the system display language is "English" or "Japanese".

However, if I uncomment the [Languages] section, the installer still runs to completion without complaint, but does not make the registry entries for "Docpath" and "Regpath", and it does not install the two PDF files the script names.

The installed program works just fine as well, except that it is unable to locate its documentation or personalization data, as it depends on those registry entries to find those data.

The only difference in the two cases is whether the [Languages] section is commented out or not. It makes no difference whether the operating system's display language is set to English or Japanese.

Does anyone have a clue what's going on?

1
Cannot reproduce with Inno Setup 5.5.5 on Windows 7 64-bit. Are you sure you were checking the correct registry node ?TLama
I'm using 5.5.4 on a 32-bit system. My target test machine is also a 32-bit Windows 7, with Japanese installed as the primary language. Besides running my app, I also did a reg query to dump the relevant registry sections, and the Docpath and Regpath entries are simply missing. Same process on same machine with installer built with no [Languages] section has clearly visible entries of those items.Logicrat
Weird. Could you try to /LOG the setup to see if there's not something suspicious ? I'm quite out of ideas why would it fail (and don't have Japanese Windows).TLama
I will try that, and I am also upgrading to Inno Setup 5.5.5 to see if that helps.Logicrat
@TLama I got version 5.5.5 and everything started working. I now have an installer working in English and Japanese. :)Logicrat

1 Answers

2
votes

If you're writing to HKLM, then you must have an admin installation.

It's not recommended to access {user*} in an admin installation, because this is a user-specific location and:

  1. Only one user installs the application, while multiple users could run it, thus you cannot rely on any per-user action done by the installer anyway (you must duplicate this in the application -- or better yet, do it only in the application).

  2. The user installing the application is not necessarily the user who will be running it -- and sometimes the user account that the installer is running as is not the account of the user who thinks they're installing it.

If you are installing common data, you should install it to the {common*} paths instead of to the {user*} paths (and bear in mind that this will be read-only to the application). If you really need the data to be per-user, then you should install it on application start (from some common template or internal default) instead of at installation time.

However in this specific case, since you appear to be installing documentation, you shouldn't be putting that in the user's (or the common) Documents folder anyway -- you should put it in {app} along with the rest of your application's files.