текущий язык интерфейса AutoCAD

[Николай Горлов]

"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "ru-RU" - это запускает 2015 автокад с русским языковым пакетом.
"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "en-US" - запускает 2015 автокад с английским пакетом.

Собственно говоря, автокад один и тот же, разные только языковые пакеты. И вот находясь уже внутри запущенного автокада, как через ARX можно узнать, какой языковой пакет используется?

[Андрей Бушман]

Попробуй GetThreadLocale. А если нужно не просто LCID, но имя локали, то затем LCIDToLocaleName.

[Николай Горлов]

увы, но ЭТО работает так же как и системная переменная акада LOCALE. при загрузке и русской и английской локализации я получаю "ru-RU" в случае использования LCIDToLocaleName, и "RUS" в случае использования системной переменной. просто оно всё берет данные в переменных виндузов, что никак не поможет понять какой язык у меня именно в автокаде. если, например, виндуза болгарские, а автокад китайский, то на возврат придет код болгарии )))

[Андрей Бушман]

Как вариант, ты можешь из C++ получить значение свойства Thread.CurrentThread.CurrentUICulture. Я манипулировал им на C#, динамически меняя локализацию интерфейса своих плагинов и вызываемых справок в акаде (тынц).

[Андрей Бушман]

А вот и "родной" способ: GetThreadUILanguage. А если нужно менять, то SetThreadUILanguage.

[Александр Ривилис]

Или acrxProductLCID(); или AcDbHostApplicationServices::getRegistryProductLCID();
Первую функцию я использую в моём приложении GeomProps, в котором в зависимости от языка локализации строки в Панели свойств на русском или на английском.
В AutoCAD 2017 вместо acrxProductLCID() используйте acrxProductLocale();

P.S.: В AutoCAD .NET API это Autodesk.AutoCAD.Runtime.SystemObjects.DynamicLinker.ProductLcid

[Андрей Бушман]

Или acrxProductLCID(); или AcDbHostApplicationServices::getRegistryProductLCID();

Указанные мною выше варианты вроде тоже должны работать... Проверить не могу, т.к. для моих кадов установлена только одна локаль (en-US).

[Александр Ривилис]

Указанные мною выше варианты вроде тоже должны работать...

Сейчас попробую, но думаю что не работают.

[Андрей Бушман]

но думаю что не работают

На чём основано предположение? Ведь в конечном счёте мы все играем по правилам, установленным WinAPI и ежели я в C# манипулировал этим свойством через Thread.CurrentThread.CurrentUICulture, то логично предположить, что и в C++ должно получиться через  GetThreadUILanguage и SetThreadUILanguage...

[Николай Горлов]

воспользовался acrxProductLCID(). помогло. уж думал придется в реестр лезть и анализировать переменную LastLaunchedLanguage для текущей версии автокада ))). всем спасибо, вопрос решен

[Александр Ривилис]

Код:

Код - C++ [Выбрать]

1. static void GetLCIDGetLCID ()
2. {
3.     acutPrintf(_T("\nacrxProductLCID()=%d"),acrxProductLCID());
4.     acutPrintf(_T("\nAcDbHostApplicationServices::getRegistryProductLCID()=%d"),
5.       acdbHostApplicationServices()->getRegistryProductLCID());
6.     acutPrintf(_T("\nGetThreadUILanguage()=%d"), GetThreadUILanguage());
7. }

Результаты проверки.
AutoCAD 2015 English:

Command: GETLCID
acrxProductLCID()=1033
AcDbHostApplicationServices::getRegistryProductLCID()=1033
GetThreadUILanguage()=1049

AutoCAD 2015 Russian:

Команда: GETLCID
acrxProductLCID()=1049
AcDbHostApplicationServices::getRegistryProductLCID()=1049
GetThreadUILanguage()=1049

Так что GetThreadUILanguage() в AutoCAD возвращает LCID не AutoCAD, а Windows

[Александр Ривилис]

воспользовался acrxProductLCID(). помогло. уж думал придется в реестр лезть и анализировать переменную LastLaunchedLanguage для текущей версии автокада ))). всем спасибо, вопрос решен

Главное, что этот метод работает начиная как минимум с AutoCAD 2006 и не требует переделок...

[Николай Горлов]

Главное, что этот метод работает начиная как минимум с AutoCAD 2006 и не требует переделок...

это замечательно ))).
просто пришло распоряжение свыше ))) запихнуть что-нибудь в ExchangeApps на пробу. Полазил, посмотрел, пока есть непонятные места, но решил начать именно с распознавания языка, чтоб при загрузке приложения человек сразу попадал в русский или английский интерфейс команды, в зависимости от языка автокада. так что лёд тронулся )))

[Андрей Бушман]

чтоб при загрузке приложения человек сразу попадал в русский или английский интерфейс команды, в зависимости от языка автокада.

У нас официально утверждена к использованию именно английская локализация. Юзеры привыкли использовать в консоли английские варианты команд и их псевдонимов (aliases from acad.pgp file).

Однако тексты сообщений, выводимые плагинами в консоль, а так же содержимое их диалоговых окон, предпочитают видеть всё же на русском, если такая возможность присутствует. Именно поэтому в своих реализациях я даю возможность юзерам указать в общих настройках, какие локализации  и где они хотят иметь в процессе работы:

• Какую локаль использовать при консольном выводе информации, а так же в открываемых плагином диалоговых окошках
• Какую локаль использовать для справочной системы плагина (файл справки, открываемой нажатием F1)

Поскольку далеко не все сильны в английском...

[Николай Горлов]

этот подход хорош для больших программных пакетов, где при первом запуске спрашивается, на каком языке предпочтительней получать информацию и общаться с программой. в данном случае - одна команда, где работа идет через командную строку (правда, в качестве опции, есть возможность зайти в окно "Настройки"). Ну и по логике вещей, если у человека стоит английский автокад, а по умолчанию всё на китайском, то до окна настроек он может и не добраться, чтоб переключить язык ))).
тем более, в ExchangeApps, если я правильно понял их требования, файлы на рассмотрение нужно отправлять в архиве, а не в собственном навороченном инсталляторе (в котором из наворотов для одной команды будет аж выбор языка "по умолчанию"). так что, сугубо моё мнение, для одной команды нет смысла заморачиваться с переключением языка во время её работы.