Программно подгружаю Partial CUI\CUIx (в зависимости от версии AutoCAD) файл меню.Судя по коду ты его в AutoCAD не загружаешь. Полная аналогия с тем, что ты правил lisp-файл, но забыл загрузить его в AutoCAD и поэтому выполняется предыдущая версия. Чтобы подгрузить cui/cuix нужно выгрузить и загрузить повторно меню (выполнить команды _CUIUNLOAD и_CUILOAD). Подробнее смотри пример samples\dotNet\CuiSamp в ObjectARX SDK 2007.
Судя по коду ты его в AutoCAD не загружаешь. Полная аналогия с тем, что ты правил lisp-файл, но забыл загрузить его в AutoCAD и поэтому выполняется предыдущая версия.Похоже, что вы невнимательно смотрели мой код. Ещё раз гляньте на строки 41-53. Или же вы хотите сказать, что метод AddPartialMenu не выполняет загрузку меню и её появление (после выполнения обозначенного кода) в перечне подгруженных CUI\CUIX, а так же появление в текущем Workspace ничего не означает? Никакая "предыдущая" версия выполняться не может по той простой причине, что её попросту нет. Кроме того, прежде чем запускать код на исполнение я проверял отсутствие загрузки моего файла в списке подгруженных Partial CUI\CUIX.
Никакая "предыдущая" версия выполняться не может по той простой причине, что её попросту нет.Есть. В данном случае это файл acad.cui (или acad.cuix). Ты не понял самого главного - CustomizationSection (да и все связанные с ним классы) работает с файлом меню, но никак не влияет на загруженное в AutoCAD меню. Точно так же как редактор для lisp-файлов (например, Notepad) не занимается загрузкой lisp-файлов в AutoCAD.
Или же вы хотите сказать, что метод AddPartialMenu не выполняет загрузку меню и её появление (после выполнения обозначенного кода) в перечне подгруженных CUI\CUIX, а так же появление в текущем Workspace ничего не означает?Именно это я и хочу сказать. Команда _CUI работает с файлом меню и производит его загрузку/перезагрузку только по кнопке Apply или OK.
Все менюшки я создаю и заполняю программно, при загрузке dll в IExtensionApplication.InitializeИконки при таком подходе хранишь в виде набора отдельных файлов? Ведь ресурсный DLL сопоставляется с существующим CUI\CUIX.
Вон оно как... Я думал, что правка выполняется как раз текущего, загруженного меню, с сохранением изменений в файл через вызов Save().Фактически это только обертка над xml. Более того, насколько я помню AcCui.dll единственная из AutoCAD'овских .NET-сборок, которая может использоваться не только в dll-приложении для AutoCAD, но и в любых внешних приложениях. Во всяком случае так было раньше. В последних версиях я не проверял.
Но вроде бы в них это можно сделать через COM/ActiveX:В ObjectARX SDK не вижу информации об этих методах. Каковы сигнатуры их вызова для AutoCAD 2009-2011? Попробую выполнить загрузку через позднее связывание. Приводит ли такая загрузка к автоматическому внесению правок и в сам файл CUI\CUIX или же изменения применятся только к текущей сессии?
1) MenuGroup имеет метод Unload для выгрузки меню
2) MenuGroups имеет метод Load для загрузки меню
В ObjectARX SDK не вижу информации об этих методах.COM/ActiveX не входят в состав ObjectARX. Документация к ним отдельная. Например, эта: http://help.autodesk.com/view/ACD/2017/ENU/?guid=GUID-5D302758-ED3F-4062-A254-FB57BAB01C44
Приводит ли такая загрузка к автоматическому внесению правок и в сам файл CUI\CUIX или же изменения применятся только к текущей сессии?Ты правишь CUI\CUIX через CustomizationSection (и иже с ним), а загружаешь через COM/ActiveX
2) MenuGroups имеет метод Load для загрузки менюLoad успешно загружает меню и отображает Toolbars (т.е. с этим всё в порядке). Но для того, чтобы отобразились Ribbons приходится вручную переключиться на др. Workspace и обратно. Как этот момент обойти?
Но для того, чтобы отобразились Ribbons приходится вручную переключиться на др. Workspace и обратно. Как этот момент обойти?Переключиться программно. Системная переменная WSCURRENT.
Переключиться программно. Системная переменная WSCURRENT.Я как раз и не хочу выполнять регенерацию риббонов этим способом, т.к. мелькание перед юзером переключающегося воркспейса - это плохой способ регенерации.
Фактически это только обертка над xml. Более того, насколько я помню AcCui.dll единственная из AutoCAD'овских .NET-сборок, которая может использоваться не только в dll-приложении для AutoCAD, но и в любых внешних приложениях. Во всяком случае так было раньше. В последних версиях я не проверял.Полезная информация!
Мне не нравится, что приходится переключать рабочее пространство, дабы риббоны появились. Если так будет поступать каждое расширение, то тормоза неизбежны...А ты что это делаешь при каждом запуске AutoCAD или только тогда, когда твоё меню не загружено? Если однократно, то я не вижу проблем.
Иконки при таком подходе хранишь в виде набора отдельных файлов? Ведь ресурсный DLL сопоставляется с существующим CUI\CUIX.Нет иконки храню в ресурсах, которые разворачиваю в %TEMP% и загружаю через COM SetBitmaps.
Про состояние я уже писал - вначале проверяю есть ли такой toolbars - если он есть (а соответственно есть и где он лежит,как виден и пр.) - то просто добавляю кнопки на него, если нету создаю свой новый.Вот тут то собака и зарыта. Если добавляешь свои кнопки в один из стандартных toolbar AutoCAD, то за свойствами этого toolbar следит AutoCAD и сохраняет его между сеансами работы. А вот если тебе приходится создавать на лету свой toolbar, то всё становится крайне неприятным. Если ты не будешь запоминать положение этого toolbar, то пользователя это будет раздражать. Ему придётся при каждом запуске его куда-то перетаскивать или вообще закрывать toolbar, если он не нужен. cui(x) берут это на себя запоминание положений toolbar'ов.
Если добавляешь свои кнопки в один из стандартных toolbar AutoCAD, то за свойствами этого toolbar следит AutoCAD и сохраняет его между сеансами работы. А вот если тебе приходится создавать на лету свой toolbar, то всё становится крайне неприятным. Если ты не будешь запоминать положение этого toolbar, то пользователя это будет раздражать. Ему придётся при каждом запуске его куда-то перетаскивать или вообще закрывать toolbar, если он не нужен. cui(x) берут это на себя запоминание положений toolbar'ов.Это основная причина по которой я всегда был и есть против программного создания менюшек в акаде.
Если ты не будешь запоминать положение этого toolbar, то пользователя это будет раздражать. Ему придётся при каждом запуске его куда-то перетаскивать или вообще закрывать toolbar, если он не нужен. cui(x) берут это на себя запоминание положений toolbar'ов.Неоднократно присутствовал при таких ситуациях (у некоторых юзеров понакачено из инета). Преимущественно от пользователя в этот мометн слышался мат и недоумение о том, почему "оно" не может запомнить "своё" место.
Вот тут то собака и зарыта. Если добавляешь свои кнопки в один из стандартных toolbar AutoCAD, то за свойствами этого toolbar следит AutoCAD и сохраняет его между сеансами работы. А вот если тебе приходится создавать на лету свой toolbar...Еще раз - он создается если с таким именем его нет. Если пользователю надо чтоб он оставался там где ему надо - он создает свой пустой и ставит куда нужно. Настолько "одаренных" юзеров которые не могут по фразе команда "_cui" во вкладке панели -> добавить панель - не могут этого сделать - у нас не держат ибо основная их работа требует более интеллектуальных навыков.
Настолько "одаренных" юзеров которые не могут по фразе команда "_cui" во вкладке панели -> добавить панель - не могут этого сделать - у нас не держат ибо основная их работа требует более интеллектуальных навыков.Значит тебе очень повезло.
Значит тебе очень повезло.Тут вообще отдельная тема - не имеющая никакого отношения к программированию, но тем не менее крайне важная для "нашего брата" - уверяю что нет такого пользователя автокада, который в нем должен работать и не может разобраться (хотя-бы под запись) в чем-то типа добавления в меню. Есть либо упертые, либо зазнавшиеся или очень важные персоны - которые считают, что это им кто-то все должен. Ему можно просто отключить кнопки - и дать список команд. У меня к последней "системе" вообще никто "насильно" подключен не был - не хочешь "руби руками" пока не дозреешь до коллег, которые пол дня кофе пьют и в теннис играют - но больше (и лучше) тебя работы делают - если есть обоснованные претензии (пожелания) к функционалу - всегда рассматриваем вопрос как их реализовать - всем все равно не угодить - частично по этому и допуск разный.
Если пользователю надо чтоб он оставался там где ему надо - он создает свой пустой и ставит куда нужно.Для этой цели пользователь как минимум должен знать имя этого toolbar. Т.е. имя должно быть зарезервировано. В противном случае даже если ты добавишь к какому-то toolbar'у свою кнопку, то как об этом догадается пользователь если у него этих toolbar'ов пару десятков на экране? Это (описать как следует назвать toolbar'ы для твоих приложений) можно сделать в своей организации, но для коммерческого продукта - это плохой стиль (IMHO).
Если пользователю надо чтоб он оставался там где ему надо - он создает свой пустой и ставит куда нужно.ИМХО - это лишнее телодвижение для пользователя, которое можно было бы легко избежать в случае использования CUI\CUIX.
Кстати, что-то в Диминой идее мне кажется есть. Но вот если совместить его идею и CUI\CUIX с пустыми toolbar'ами, которые он наполняет, то возможно получится неплохой вариант...Если пользователю надо чтоб он оставался там где ему надо - он создает свой пустой и ставит куда нужно.ИМХО - это лишнее телодвижение для пользователя, которое можно было бы легко избежать в случае использования CUI\CUIX.
Кстати, что-то в Диминой идее мне кажется есть. Но вот если совместить его идею и CUI\CUIX с пустыми toolbar'ами, которые он наполняет, то возможно получится неплохой вариант...Мне в этой идее не нравится такой момент, что юзер, имеющий опыт работы с CUI\CUIX, может быть сбит с толку таким поведением, не понимая, почему в различных условиях состав одного и того же Toolbar может отличаться. Он ведь не в курсе программной обработки менюшек. Ну, либо это должно быть документировано в справке расширения.
Он ведь не в курсе программной обработки менюшек.Зато можно реализовать что-то наподобие "контекстных toolbar". Например, выбраны полилинии - одни кнопки по работе с ними, выбраны сплайны - другие кнопки... Может быть даже весело. :)
Зато можно реализовать что-то наподобие "контекстных toolbar". Например, выбраны полилинии - одни кнопки по работе с ними, выбраны сплайны - другие кнопки... Может быть даже весело. :)http://bushman-andrey.blogspot.ru/2012/10/autocad.html
Более того, насколько я помню AcCui.dll единственная из AutoCAD'овских .NET-сборок, которая может использоваться не только в dll-приложении для AutoCAD, но и в любых внешних приложениях. Во всяком случае так было раньше. В последних версиях я не проверял.
Не удалось загрузить файл или сборку "Acdbmgd, Version=20.1.0.0, Culture=neutral, PublicKeyToken=null" либо одну из их зависимостей. Была сделана попытка загрузить программу, имеющую неверный формат.
Press any key for exit...
Была когда-то тонкость (или в 2006-ом или в 2007-ом) и мне о ней рассказал Tony Tanzillo, что для того чтобы эта сборка работала приложение должно находится в каталоге с acad.exe. Судя по твоему эксперименту это уже не актуально.Я тестировал оба варианта: сначала с размещением моего exe в каталоге акада, потом - с размещением в произвольном каталоге.
P.S.: Нашёл это обсуждение: https://forums.autodesk.com/t5/net/install-toolbar-cui-net-api/td-p/1748176
Во втором случае для разрешения конфликтов ссылок я воспользовался событием AppDomain.AssemblyResolve. Это позволило не размещать мои сборки в каталоге акада для использования AcCUI.dll.Ага. Т.е. проблема с разрешением ссылок для AcCui.dll сохранилась и в более новых версиях.
Т.е. проблема с разрешением ссылок для AcCui.dll сохранилась и в более новых версиях.Это не проблема и соответствует поведению, по поиску ресурсов, свойственному любому .NET приложению. AppDomain.AssemblyResolve как раз и существует в качестве вспомогательного инструмента уже много лет. Использование обозначенного метода я демонстрировал ещё в 2011-м году, например, в этой (https://sites.google.com/site/bushmansnetlaboratory/moi-zametki/netunload) песочнице.
AppDomain.AssemblyResolve как раз и существует в качестве вспомогательного инструмента уже много лет. Использование обозначенного метода я демонстрировал ещё в 2011-м году, например, в этой песочнице.2011-ой это не 2007-ой, но ты прав. Я посмотрел, что это событие было даже в .NET 1.1 и соотвественно могло использоваться даже в AutoCAD 2006: https://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve%28v=vs.71%29.aspx
Какие изменения мне нужно выполнить (в реестре либо в файлах), чтобы при очередном старте AutoCAD корректно загрузил в т.ч. и файл частичного меню, который я программно указал в качестве подключенного в основном файле меню (например в acad.cuix)?Ну наверное тебе нужно поработать еще и с Workspace в acad.cuix через AcCui.dll
Ну наверное тебе нужно поработать еще и с Workspace в acad.cuix через AcCui.dllДа, похоже на то...