On Wed, Nov 20, 2024 at 12:15 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Idea: could the Visual Basic program actually be using a different
> ACP, not the one in the registry, due to some explicit locale setting
> or environment variable somewhere? Would it be better to call
> GetACP() instead of that registry lookup[2]?
Guessing harder, in more actionable form: something like
LANG="fr-FR.UTF-8" might be enough to break your script, if VB itself
or something in your VB code calls setlocale(LC_ALL, ""). I have no
idea if it does, but if so, that could change the ACP for the process,
I think. Perhaps Gursharan might like to check whether LANG or any of
the LC_ is set in the environment where the installer runs, and if so
whether the value implies a codepage that doesn't match
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP.
If so, just as an experiment, changing the variable to something with
a matching codepage (I think for example "fr-FR" without suffix
implies 1252, traditional encoding used for French) might work, just
to confirm what's happening, or kill this theory :-) And if that's
it, and if GetACP() is the solution, then: the intergoogles told me
that you should be able to 'Declare Function GetACP Lib "kernel32" ()
As Long' to access it.
