КРАТКОЕ СОДЕРЖАНИЕ:
Моя цель — избежать двойного запроса предпочтительного языка пользователя: в установщике и в приложении, когда пользователь устанавливает программное обеспечение в профиль общего пользователя.
Я знаю, как использовать выбор языка в установщике, когда пользователь устанавливает приложение для текущего пользователя. Мой вопрос в том, как мне действовать, если пользователь устанавливает приложение для всех пользователей, а выбор языка хранится в корне реестра HKLM
.
Я создал программное обеспечение с поддержкой нескольких языков пользовательского интерфейса. Когда пользователь меняет язык в приложении, я сохраняю его в реестре (HKCU
root) при выходе из приложения. Когда приложение запускается, оно считывает язык обратно из реестра. Кажется, эта часть тривиальна.
В моем сценарии установки Inno я разрешаю пользователям выбирать язык установщика, а затем сохраняю этот выбор в той же ветке реестра, которая используется установленным приложением (чтобы не заставлять пользователя выбирать язык дважды: в установщике, а затем в приложение). Пока еще ничего сложного.
Когда я добавил пользователям возможность устанавливать приложение в общий профиль (т. е. «Все пользователи»), все стало намного сложнее.
Проблема в том, что HKA
сопоставляется с корнем HKLM
, когда пользователь выбирает «Все пользователи», но приложение работает с корнем HKCU
, поэтому ничего там не находит.
Вот основные моменты из моего сценария установки Inno:
[Setup]
PrivilegesRequiredOverridesAllowed=dialog ;to let users to choose the target user profile, is it correct?
...
[Languages]
Name: en; MessagesFile: "compiler:Default.isl"
Name: de; MessagesFile: "compiler:Languages\German.isl"
Name: fr; MessagesFile: "compiler:Languages\French.isl"
Name: it; MessagesFile: "compiler:Languages\Italian.isl"
...
[Registry]
Root: HKA; Subkey: "Software\{#MyAppName}\Settings"; ValueType: string; ValueName: "Language"; ValueData: "en"; Languages: en
Root: HKA; Subkey: "Software\{#MyAppName}\Settings"; ValueType: string; ValueName: "Language"; ValueData: "de"; Languages: de
Root: HKA; Subkey: "Software\{#MyAppName}\Settings"; ValueType: string; ValueName: "Language"; ValueData: "fr"; Languages: fr
Root: HKA; Subkey: "Software\{#MyAppName}\Settings"; ValueType: string; ValueName: "Language"; ValueData: "it"; Languages: it
...
Итак, мои вопросы:
В таких условиях должно ли мое программное обеспечение всегда сначала читать язык из корня HKLM
, а если не найден, переключаться на HKCU
? Если да, то приложение нужно запускать от имени администратора, верно?
В качестве альтернативы я мог бы продублировать часть реестра и сохранить язык в корне HKCU
независимо от выбора профиля. А смешивать профили в скрипте настройки, кажется, плохая практика? И это помогает только текущему пользователю...
Может быть, я слишком усложняю задачу и существуют более простые способы? Какова общепринятая практика достижения моей цели (если такая практика существует)?
Вероятно, вопрос шире, чем просто установка Inno и реестр, но я не смог найти, как правильно его классифицировать. Любая помощь с категоризацией приветствуется.
Может быть, я слишком усложняю задачу и существуют более простые способы? Какова общепринятая практика достижения моей цели (если такая практика существует)?
Да, я считаю, что вы слишком усложняете этот вопрос. Все, что вам нужно сделать, это изменить логику вашего собственного приложения при его запуске.
HKLM
и установите его по умолчанию.Это не вопрос установки Inno.
В таких условиях должно ли мое программное обеспечение всегда сначала читать язык из корня
HKLM
, а если не найден, переключаться наHKCU
? Если да, то приложение нужно запускать от имени администратора, верно?
Для чтения HKLM
вам не нужны права администратора. Чтобы написать HKLM
, вам нужны права Амина.
Вы не говорите, какая у вас среда кодирования или что-то еще для вашего приложения, но я использую CSettingsStore, чтобы упростить чтение данных реестра из HKLM
и т. д..
Чтение реестра не проблема. Меня просто интересовал концептуальный подход, когда некоторые настройки приложения смешиваются между HKCU и HKLM. Спасибо, ваш ответ пролил свет на этот вопрос.