Для чего в локализованную версию устанавливать нелоколизованную справку (и наоборот, зачем в базовой версии сваливать все локализации)??А для чего в программах имеется возможность переключение между локализациями? Или Вы и это считаете "сваливанием всех локализаций"? Или же по-Вашему это нормально, когда юзер указывает удобную ему локализацию, а справка остаётся от прежней локализации (именно это и получится, если следовать Вашим рекомендациям)?
Класть "правильную" справку нужно во время установки...Получается, что решение о том, какая локализация справки является "правильной" решаете Вы, а не пользователь, переключающий локализацию приложения. Это неправильно. 99% моих .NET-плагинов под AutoCAD - это обычные zip архивы, а не MSI, которые в данном контексте считаю ненужными.
Т.е. локализацией в этой функции не пахнет. С другой стороны можно проверить текущую локализацию и запустить эту функцию с нужными параметрами в зависимости от локализации. Кстати, и в .NET через P/Invoke это сделать достаточно просто.Я не спрашивал о том, как проверять текущую локализацию или менять её - это я прекрасно умею делать (причём без всяких P/Invoke). Мой вопрос был совсем о другом.
а где Вы видели в автокаде переключение локализаций на лету (как это действительно есть во многих других программах).А я и не писал о переключений локализаций на лету для самого AutoCAD... Я писал о смене локализаций применительно к плагинам. Такое переключение делается достаточно просто и время от времени в своих .net плагинах я это делаю (когда не ленюсь). Значение желаемой локализации (её имя) хранится в файле настроек плагина. Если указанная не найдена, то используется та, что Default. Если найдена - то на момент работы команды текущей устанавливается та, что указана (локализация интерфейса) и по завершению работы возвращается прежняя. Если в файле настроек указать др. локализацию, то следующий вызов команды плагина применит эту локализацию (перезагрузка не требуется). Но по умолчанию происходит считывание той локализации, которую имеет AutoCAD. Поэтому, если AutoCAD английский, то и локализация в плагине будет искать прежде всего английскую, а если AutoCAD русский - то русскую. Если пользователь захочет для плагина принудительно указать иную (например, русскую в английском автокаде), то может сделать это в настройках. И заметьте: этот механизм не я придумал - это родной механизм, реализованный в .NET, а я всего лишь пользуюсь им (как и AutoCAD, применительно к localizedNameId).
Да есть соответствующие механизмы (и не только в .Net) для выбора соответствующих библиотек, но к автокаду-то это не относится. По моему, то что формат хранения Ваших плагинов на данном этапе "не дружит" с локализацией (то есть, дружит, но с тем вариантом который есть в .Net, но отсутствует в Автокад) - это Ваш баг, а не автодеска.Прочитайте внимательней ещё раз первое сообщение данной темы... AutoCAD как раз таки использует механизм, реализованный в .NET - ещё раз смотрите на параметр localizedNameId. Но разработчики реализовали это так, что используют его только для одного параметра, хотя по хорошему следовало сделать это для трёх. Это недоработка обёртки!
Реализовывать или нет соответствующие "навороты" системы решать имЭто не "навороты", а недоделка, исправление которой укладывается в две строки кода. Я бы не задавал такого вопроса, если бы и localizedNameId не обращался к локализованным ресурсам. Но если уж начали делать, то доделывайте до конца (имхо).
Не забывайте, что автокад (пока) написан не на .Net и все что видно из него - это только оберткаЯ пишу не об абстрактном сферическом коне в вакууме, а о конкретной ситуации. Кроме того, как я уже писал выше - исправление занимает всего две строки кода.
Баг, это всё что угодно, что заставляет пользователя страдать:
- аварии и зависания
- низкая производительность и масштабируемость
- неверные результаты
- нарушения безопасности
- противоречивые пользовательские интерфейсы
- неудовлетворённые ожидания
4. В теме я обозначил конкретную проблему и обозначил способ её решения, который достаточно просто реализуется (см. код ниже).Решение этой проблемы породит кучу проблем для них самих - а именно переработку массы собственных и сторонних команд, которые используют тот же конструктор. Единственный вариант, это создание еще одного конструктора.
Причем локализованное имя команды зависит только от локализации самого AutoCAD.Да это всё понятно...
Если же тебе нужно расширить возможности локализации своего плагина (например, переключать локализацию налету) - тут тебе придется поработать самому.Эту работу я без проблем делаю одной единственной строкой кода. Да услышьте же Вы меня на конец: у меня нет проблем с переключением локализаций своего плагина!!! Проблема в том, что когда пользователь набирает в консоли AutoCAD имя моей команды и, не нажимая Enter, жмёт клавишу F1, то открываться будет всегда один и тот же файл справки, не зависимо от локализации как плагина так и AutoCAD. Это неправильно!
Единственный вариант, это создание еще одного конструктора.Ну или так... Важен результат, а не цвет "фенечек".
В данном случае, видя в плагине русский интерфейс, он ожидает увидеть русскую справка, а при виде английского - английскую.Повторюсь. Логика работы AutoCAD во все времена: "язык плагина" == "язык AutoCAD". Соответственно и справка должна быть на том языке, на котором AutoCAD. Например, в IExtensionApplication.Initialize ты копируешь в нужное место соответствующий языку локализации файл. И тогда AutoCAD будет использовать именно его.
Проблема в том, что когда пользователь набирает в консоли AutoCAD имя моей команды и, не нажимая Enter, жмёт клавишу F1, то открываться будет всегда один и тот же файл справки, не зависимо от локализации как плагина так и AutoCAD. Это неправильно!Андрей. Ты это попробовал: http://adn-cis.org/forum/index.php?topic=417.msg1109#msg1109 ?
Повторюсь. Логика работы AutoCAD во все времена: "язык плагина" == "язык AutoCAD". Соответственно и справка должна быть на том языке, на котором AutoCAD.Дело в том, что в .NET нет такого понятия как "язык плагина" (если отделять локализацию от кода, что собственно я обычно и делаю): один и тот же плагин может быть установлен как в русском, так и в английском AutoCAD. А поскольку локализованные ресурсы выносятся в отдельный файл ресурсов (dll), то нужная локализация автоматически находится и подставляется самой .NET, в виду чего один и тот же плагин в английском автокаде отображает английский интерфейс, а в русском - русский. Но сам по себе плагин (dll файл с кодом команд) один. А вот справка... Она же читается не автоматом из dll, а из файла chm, который нужно как-то указать уникально для каждой локализации свой...
В данном случае чтобы реализовать то, что нужно Андрею, следует в методе IExtensionApplication.Initialize проверить локализацию и вызвать acedSetFunHelp с параметрами, зависящими от локализации. В этом случае нажатие F1 в AutoCAD для данной команды (команд) должно приводит к вызову соответствующей справки.Я не увидел этот ответ, только сейчас заметил. Да, нужно будет попробовать, хотя у меня безуспешные попытки вроде уже были (http://adndevblog.typepad.com/autocad/2012/05/change-help-file-and-topic-associated-to-a-given-command.html).
Фактически acedSetFunHelp занимается тем, что заносит во внутреннюю таблицу AutoCAD тройку строк имя команды-имя файла помощи-имя раздела помощи. При нажатии F1 AutoCAD проверяет эту таблицу и вызывает нужный раздел нужной справки.
Например, в IExtensionApplication.Initialize ты копируешь в нужное место соответствующий языку локализации файл.Хм... Как вариант, конечно же подходит, если файлы справки хранятся в каталоге, доступном юзеру для редактирования (например, в %AppData%).
Чтобы справка открывалась не только под отладкой, нужно в каталоги поиска САПР (Support File Search Path) добавить путь к каталогу плагина (в абсолютной или относительной форме).Если это выполнять для каждого плагина, то сами понимаете, во что превратится Support File Search Path... Было бы неплохо, если бы AutoCAD искал справку плагина относительно каталога его сборки.
Ну, давайте, закидывайте меня бананами...Бананами не буду. Если использовать технологию с acedSetFunHelp то просто пропишешь полные пути и всё. А вот с учетом того, что и для CommandAttribute используется тот же acedSetFunHelp и после этого AutoCAD уже понятия не имеет о том, что этот вызов был из твоего модуля - тут вряд ли возможно что-то сделать.
Defines a Help call that should be made if a transparent Help request is made during a command line prompt for the function named pszFunctionName.По началу, меня несколько насторожило отсутствие упоминания команд, написанных на .NET... Однако практика показала, что опасения были напрасны. В качестве "подопытной кошки" выступал chm-файл, прикреплённый во вложении.
This function registers Help for functions that are called from the AutoCAD command line so that the appropriate Help file and topic are called when help is requested at a user prompt. acedSetFunHelp() may be used for ObjectARX commands, as well as ObjectARX and AutoLISP commands that start with C:.
Hi, Adam!
What about that LINE is not Autolisp-definded command and so you have to use not "C:LINE", but "LINE" in your's code?
Кончено в зависимости от ситуации, но "топорный" метод проверки локализации и переноса в случае необходимости .chm может быть даже более "интересным" - например в случае 1 сборка, 1 .chm и кучка команд.я не понял этой фразы.
но зато (если 1 справка на все команды), не париться с установкой на каждую команду (то есть исключаються варианты типа добавил команду в сборку, в справку, но забыл ее правильно инициализировать).А как AutoCAD будет знать, что ему нужно обработать еще одну команду? Т.е. в любом случае для каждой команды нужен будет свой CommandAttribute с именем файла справки и раздела справки. Хотя идею с IExtensionApplication.Initialize можно развить на "правильном" пути - при помощи Reflection получить все команды в сборке и им назначить через acedSetFunHelp справку. Вот тогда действительно можно будет "не парится" с назначением помощи каждой из команд.
Хотя идею с IExtensionApplication.Initialize можно развить на "правильном" пути - при помощи Reflection получить все команды в сборке и им назначить через acedSetFunHelp справку. Вот тогда действительно можно будет "не парится" с назначением помощи каждой из команд.Именно это я сейчас и делаю в качестве примера... :)
А вот в AutoCAD 2009 SP3, для определённых мною .net команд, это работает во всех трёх ситуациях (риббон\туллбар\командная строка). ;DСтранно. В той же статье Адам Наги пишет, что для тултипов работать не должно - нужно править CUIx.
Странно. В той же статье Адам Наги пишет, что для тултипов работать не должно - нужно править CUIx.Я в CUI создал новую кнопку, палитру кнопок, палитру риббона, вкладку риббона. Назначил кнопке свою команду test. Добавил в текущий workspace свою вкладку риббона и обычную палитру с кнопкой. Вот на этом и тестировал.
Т.е. в любом случае для каждой команды нужен будет свой CommandAttribute с именем файла справки и раздела справкиДа нужно, но она 1 - не надо будет "обрабатывать" каждую команду. То есть делаешь аттрибут как будто справка на 1 языке, и забываешь.
Будет интересно посмотреть и покритиковать! :)
Второй вариант конечно имеет свои преимущества, но при переходя на другую версию .NET (как я понимаю) потребуется перекомпиляция подключаемой DLL...Но Вас же не пугает то, что каждый третий год Вам приходится выполнять перекомпиляцию ваших ARX программ? Почему же Вас пугает то, что при переходе на очередную версию .NET (или при внесении изменений в функционал API, используемый в Вашем плагине) придётся перекомпилировать управляемый плагин? :)
Хоть мне и не надо - но по моему правильней второй. Но ИХМО указывать сборку это "вторая" перегрузка, по умолчанию - та откуда вызван метод.Я буду Вам весьма признателен, если Вы постараетесь более развёрнуто излагать свои мысли. Нередко мне достаточно сложно понять то, что Вы пытаетесь написать: либо вообще не понимаю, либо возникает неоднозначность, либо понимаю неправильно.
Будет интересно посмотреть и покритиковать!Можете приступать. Опубликовано здесь (http://bushman-andrey.blogspot.ru/2013/12/autocad_29.html).
Обратите внимание на скрины консоли: AutoCAD 2014 SP1 "сливает" всё форматирование (пустые строки, посредством которых я группирую информацию).Для проверки написал такое:
Больше ничего сказать не могу, так как не вижу исходника Bushman.CAD.PluginServices.Значит вы не до конца прочитали, т. к. все исходники там присутствуют - в самом конце заметки выложен архив с проектом.
Если я правильно понял твой код, то на время действия своих команд ты переключаешь системную локализацию. Я бы был с этим крайне осторожен, так как она влияет и на вывод разделителя целой и дробной части действительных чисел.Культура культуре рознь... Вы мне пишете об этой (http://msdn.microsoft.com/ru-ru/library/system.threading.thread.currentculture(v=vs.110).aspx). А я временно переключаю совсем другую - вот эту (http://msdn.microsoft.com/ru-ru/library/system.threading.thread.currentuiculture(v=vs.110).aspx). Но если бы вы открыли исходники, которые я выложил в той же заметке в виде архива, то смогли бы и сами это увидеть. ;)
Значит вы не до конца прочитали, т. к. все исходники там присутствуют - в самом конце заметки выложен архив с проектом.Я намекал, но ты не понял, что исходники не полные (в архиве нет проекта NetExtensions целиком), т.к. архивировал ты только одну папку.
Культура культуре рознь... Вы мне пишете об этой. А я временно переключаю совсем другую - вот эту. Но если бы вы открыли исходники, которые я выложил в той же заметке в виде архива, то смогли бы и сами это увидеть. ;)По поводу исходников - смотри выше. По поводу культуры - будем считать, что мне показалось.
Я намекал, но ты не понял, что исходники не полные (в архиве нет проекта NetExtensions целиком), т.к. архивировал ты только одну папку.А вон оно что... Я и не заметил. :) Исправлюсь. Внёс изменения, упомянутые мною выше (отделил управление локализацией интерфейса от локализации справочной системы). Перезаписал запись блога, перезалил исходники. Можно смотреть (http://bushman-andrey.blogspot.ru/2013/12/autocad_29.html).
Я слабо себе представляю ситуацию когда для одного плагина предпочитают русскую локализацию, а для другого английскую.Если один плагин имеет русскую и английскую локализацию, а второй английскую и китайскую.
Если один плагин имеет русскую и английскую, а второй английскую и китайскую.Согласен. Теоретически такой вариант возможен.
Я бы перефразировал так:Я слабо себе представляю ситуацию когда для одного плагина предпочитают русскую локализацию, а для другого английскую.Если один плагин имеет русскую и английскую локализацию, а второй английскую и китайскую.
Если один плагин имеет французскую и английскую локализацию, а второй английскую и китайскую.Причём в первом случае в качестве default первым программистом указана французская, а во втором - китайская (вторым программистом). :)
Я так понял, что мыслей по обозначенному вопросу (о приоритетах настроек) нет :)Так как менять эти значения в реестре вручную сложнее, чем в конфигурационном файле, то (IMHO) у конфигурационного файла приоритет выше.
менять эти значения в реестре вручную сложнееДа собственно это и не проблема: можно написать команду, которая будет это делать - либо в отдельном диалоговом окне юзер из списка существующих локализаций выберет предпочитаемые, либо просто добавить на свою вкладку в диалоговом окне Options два ComboBox с выбором локализаций.
либо просто добавить на свою вкладку в диалоговом окне Options два ComboBox с выбором локализаций.А на каком языке будет эта вкладка? :D
А на каком языке будет эта вкладка? :-DНапример на C#.
Например на C#.Русский, английский, французский, китайский, язык AutoCAD, язык Windows???
Русский, английский, французский, китайский, язык AutoCAD, язык Windows???Если в реестре нет значений, то локализация вкладки будет та же, что и Windows. Если такая не будет найдена в плагине, то - локализация AutoCAD или же default, если искомые не будут найдены среди доступных локализаций плагина. Но если в реестре будет указана локализация, то в первую очередь будет пытаться примениться она. Мне кажется, что такая очерёдность будет более удобной.
Мне кажется, что такая очерёдность будет более удобной.Я бы поменял между собой приоритеты между языком AutoCAD и Windows. Считаю более естественным если по-умолчанию язык этой вкладки не будет отличатся от языка соседних вкладок.
Я бы поменял между собой приоритеты между языком AutoCAD и Windows. Считаю более естественным если по-умолчанию язык этой вкладки не будет отличатся от языка соседних вкладок.Ну тогда по такой логике и локализация плагинов и справочной системы должны быть английскими, чтобы выглядеть "более естественно". А ежели после сохранения в реестре пользовательских предпочтений, локализация вкладки будет читаться оттуда и при этом отличаться от локализации AutoCAD, то какой смысл равняться в первую очередь на локализацию AutoCAD (всё равно ведь затем локализация вкладки изменится)? Мне кажется, что локализация операционной системы с гораздо большей долей вероятности будет соответствовать предпочтениям пользователя. Английский AutoCAD предпочитают вовсе не из любви к английскому языку. :)