[TwoZero]

Здравствуйте,

Есть проблема с созданием диалоговых окон под AutoCAD,
стандартный язык для создания диалогов DCL негодится так как он очень скупой и там нет компонента TreeView, создание приложения на VBA тоже негодится так как программу пишу на ЛИСПЕ (ЛИСП РУЛИТ),
создание диалоговых окон в VB6 как ActiveX dll тоже негодится так как в дальнейшем требуется регистрировать библиотеки и если подключать дополнительные компоненты в VB6 то их придется таскать с сабой (я конечно понимаю что есть программы которые могут все запихать в один файл но такое мазуто мне ненадо), можно написать приложение на Delphi но оно будет как бы отдельное (можно конечно прописать макрос в акаде на запуск этого приложения но мне это неочень подходит так как хотелось бы чтоб все было интегрировано в акад).

Собственно проблема заключается в создании самих диалогов для AutoCAD, есть еще ObjectDCL но он платный и он перестает работать после триала.

Мож кто подскажет есть ли еще какиенить проги для создания диалогов под акад (нужен компонент TreeView).

[gomer]

Сообщение от Do$ При таком положении дел, можно писать лисп-программу, а диалог к ней - на .NET

Сообщение от hwd Не мешайте мух с котлетами...

Сообщение от Do$ проблем с версиями AutoCAD практически не должно быть.

это означает, что они таки будут

[hwd]

Сообщение от Disney hwd, буду ждать обещанного примера,

Готово. Смотри здесь.

[gomer]

Сообщение от hwd Готово. Смотри здесь.

Ну а мы вместе с ним посмеемся и вместе поплачем

hwd, вы пропагандируете хорошую штуку, внедрение в лисп, .Net в целом и WPF в частности,
но хохма в том, что ваша статья,
во-первых, так же архаична как и весь лисп с дисиэлем,
во вторых, грешит некоторыми нелепостями по поводу лисп и дисиэль
в-третьих, материал изложен не полностью и тема 'сисек' не раскрыта. Где код на лисп? Или вы считаете, что обычного вызова функции хватит и загружать библиотеку не надо? Где для сравнения код DCL?
Вообще, кроссплатформенность лисп приложений это миф, созданный для тех, кто пишет на коленке. Ну, это ладно, но чем же отличаются ваши диалоги от дисиэлевских? Безумным количеством эксэмеля и сишарпа? Зачем это надо? Выбрать из списка можно элементарно с помощью doslib. Последний пример тоже элементарно делается на DCL и лисп с гораздо меньшим количеством кода. В крайнем случае openDCL за глаза хватит для большинства диалогов, при том, что ими можно управлять из лиспа. По сути с времен появления winapi способ подачи информации в диалогах мало изменился за 20 лет, все те же поля, все те же кнопки, все те же списки... И мы все так привыкли, ничего толком не изменится в обозримом будущем, только будут рюшечки добавлятся. Есть 2 пути показать диалог - загрузить его или создать програмно, dcl - это первый путь, wpf по сути то же самое, только рюшечек больше и соответственно, да какое там, намного больше геморроя. Я уж молчу про ООП... Которое ну очень уж у вас смахивает на winapi. Все то же поиск элемента по "дескриптору" и назначение ему функции отклика... Это же есть и в DCL
а статья что? ну, на уровне реферата первого курса института или американского туториала для чайников. Ну показали бы как легко и просто 'на WPF' сделать то, что ни в жисть не сделаешь на dcl - это было бы намного интереснее, а, уж извините, отлов ошибок с помощью msgbox-ов - это незачот

[hwd]

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

[gomer]

а я не вам

[Do$]

hwd, спасибо, что находишь время для написания таких статей! Содержательно и полезно для начинающих!

Если критика не возбраняется:

технология DCL, является весьма убогим как в плане удобства его использования, так и в плане возможностей.

"убогим" лучше заменить на более нейтральное "ограниченным" или что-то подобное. Меньше негатива будет вызывать у LISP-DCL программистов .

подобно тому, как это было сделано с помощью ActiveX - результат известен как Visual LISP, хотя к LISP это можно отнести весьма условно, поскольку за кулисами основную работу выполняет иной механизм. Функции Visual LISP имеют префикс "vl-".

Функции ActiveX-расширения для лиспа начинаются на "vla-, vlax-, vlr-". Те, которые "vl-", к ActiveX не имеют отношения.

И, конечно же, выбранные примеры диалогов (в плане оформления) не демонстрируют явных преимуществ WPF над DCL. Кода тут ничуть не меньше, чем в DCL . У того, кто не разбирался с WPF, возникает вопрос - зачем что-то новое изучать, если то же самое я могу сделать в DCL? Вот если добавить контролы, которых в принципе нет в DCL (типа всплывающих подсказок, вкладок, редакторов таблиц, которые несколькими простыми телодвижениями цепляются к базе данных и т.п.), преимущества в плане возможностей стали бы более очевидны. Понятно, что на все это нужно время и силы, а аудитория типа gomer совсем не добавляет желания этим заниматься.

Хочу уточнить - почему не обойтись VS Express? Пока никаких проблем не было с ней. Или это связано с тем, что я пока не использовал WPF?

[Дима_]

То hwd - несмотря на стилистику изложения и неприязнь .Net у Gomera - он сейчас, немного запутанно, но излагает мысль в верном направлении - дело в том, что подход показанный у Вас, ну ни как не вяжется с лиспом. Допустим взял я Вашу библиотеку и хочу ее использовать - как мне создавать обертку для Х компа?, Ваш модуль уже там может быть установлен (а может и нет), причем 1001 способом - куда класть диалоги? как я проверю есть ли Ваш плагин (его может подгружать какой-либо лисп) откуда будут в итоге братся диалоги? - что дает мне то неоспоримое приемущество что я могу сам сконструировать списочный диалог?? - его надо куда-то положить, как я это место найду из лисп программы, как я лиспом буду его в UTF8 рожать (да да в лиспе принято ресурсы создавать непосредственно программой в зависимоти от "внешних" условий)? - да все это, три раза извернувшись, можно сделать - но требует соответствующей квалификации, так что не о какой простоте и быстроте в Вашем подходе речи быть не может. Если пишется функция под лисп - то ИХМО она должна играть по его правилам, иначе зачем она нужна, по императивным правилам можно и нужно писать на том же C# (в том числе и под автокад естественно). Если и делать функцию диалога для лиспа - все о диалоге (как он устроен, все рюшечки итд) должны передаваться напрямую из нее - иначе у Вас просто рождается красивый DCL, со всеми его проблемами+еще и формат его "рисования" нефига не лисповский. Я не в коем разе не хочу критиковать Ваш труд с точки зрения полезности - спасибо Вам за хорошую, качественную просветительскую деятельность в области .Net AutoCAD - говорю это искренне и с Уважением, но в понимании лисп концепции ИХМО у Вас есть пробелы (что в общем и понятно - в одну голову все влезть не может) - да и нужен-ли он Вам. Вся "беда" функциональных языков - что они плохо совместимы с ООП прагмидой, есть конечно толковые компромисы (Caml (он же F# если под .Net), Nemerle) - с большим/меньшим уклоном в ту или другю сторону. Запрос у акадовских лиспописателей - не хватает нормальных функций GUI'я работающий по лисп правилам, Вы же предлагаете - вот Вам красиво и современно - но это не то что нужно. Посмотрите туториал любого диалекта лиспа, хаскеля и др. языков функциональной прагмиды (F# не считаем там используется тот самый Caml'овский компромисс) - все API завернуты в структуры соответствующие функциональной пргамиде + на всякий случай есть "прямой вызов", по аналогии с .Net - есть обертка API в виде WinForms, а есть InteropServices для вызова натива - Вы часто в .Net используете nativ?? - полагаю только в случае крайней необходимости. Чтоб сделать реально лисповский GUI - нужна большая работа (не с проста ее не хочет делать автодеск), по разработке концепции (ну или слизывания ее с той-же Scheme - хотя и там "основная" гуишная библиотека реализованна через т.н. функциональное ООП) + куча функциональных оберток с "эмуляцией" чистоты функций. Но в любом случае, я уверен найдутся те кому Ваша статья была полезна (ну как минимум) для осознания WPF.

[hwd]

Сообщение от Do$ "убогим" лучше заменить на более нейтральное "ограниченным" или что-то подобное.

Заменил.

Сообщение от Do$ Функции ActiveX-расширения для лиспа начинаются на "vla-, vlax-, vlr-". Те, которые "vl-", к ActiveX не имеют отношения.

Исправил.

Сообщение от Do$ И, конечно же, выбранные примеры диалогов (в плане оформления) не демонстрируют явных преимуществ WPF над DCL. Кода тут ничуть не меньше, чем в DCL . У того, кто не разбирался с WPF, возникает вопрос - зачем что-то новое изучать, если то же самое я могу сделать в DCL? Вот если добавить контролы, которых в принципе нет в DCL (типа всплывающих подсказок, вкладок, редакторов таблиц, которые несколькими простыми телодвижениями цепляются к базе данных и т.п.), преимущества в плане возможностей стали бы более очевидны.

Я не ставил перед собой задачи показать, как с помощью WPF создавать навороченные диалоги, которых нельзя создать в DCL. Наоборот, указанными примерами я хотел показать, как в WPF делается то, что обычно делается в DCL, для сопоставления. XAML разметка занимает больше места, чем DCL, но она даёт и больше возможностей в плане контроля над размещением, поведением, отображением и т.п.

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

Сообщение от Do$ Хочу уточнить - почему не обойтись VS Express? Пока никаких проблем не было с ней. Или это связано с тем, что я пока не использовал WPF?

Сейчас точно уже не помню, но много лет назад мне по каким-то причинам пришлось перейти с Express на платный вариант. Чтобы вспомнить в чём дело - это нужно устанавливать Express и пытаться тыкаться в нём в различных направлениях... Ограничения точно были, но сейчас с ходу не вспомню что именно мне не хватило в той версии. Ок, в заметке убрал инфу насчёт "платной", т.к. возможно кому-то хватит и Express...

Сообщение от Дима_ дело в том, что подход показанный у Вас, ну ни как не вяжется с лиспом.

Я не понял насчёт "не вяжется". На скринах я показал, что запускаются диалоги с помощью LISP функций и в качестве значения возвращается результат в виде списка. Каждый из примеров представляет собой DLL файл. Для того, чтобы его загрузить, можно воспользоваться командой _NETLOAD. Размещать эти DLL файлы можно где угодно, на усмотрение LISP программиста, при этом указывать какие-либо дополнительные пути в диалоговом окне Options на вкладке Files не нужно.

Сообщение от Дима_ Допустим взял я Вашу библиотеку и хочу ее использовать - как мне создавать обертку для Х компа?

Не понял. Что за "обёртка для Х компа"?

Сообщение от Дима_ Ваш модуль уже там может быть установлен (а может и нет), причем 1001 способом - куда класть диалоги? как я проверю есть ли Ваш плагин (его может подгружать какой-либо лисп) откуда будут в итоге братся диалоги? - что дает мне то неоспоримое приемущество что я могу сам сконструировать списочный диалог?? - его надо куда-то положить, как я это место найду из лисп программы, как я лиспом буду его в UTF8 рожать (да да в лиспе принято ресурсы создавать непосредственно программой в зависимоти от "внешних" условий)?

То, где размещать библиотеки - решать вам. Если хотите - можете в реестре создавать запись, указывающую на то, в каком месте на конкретной машине вы храните их. Однако я в этом не вижу необходимости, поскольку при грамотном подходе, все плагины размещаются по определённой схеме. Например все лиспы находятся в подкаталогах (относительно некоторого базового каталога): .\LISP\<PluginDirName>
А все .NET библиотеки находятся в подкаталоге .\NET\<PluginDirName>.

В каталоги поиска диалогового окна Options вы можете добавить путь к этому самому "базовому каталогу", содержащему подкаталоги LISP и NET, а в своём LISP коде указывать относительный путь к DLL, наличие которой хотите определить и которую желаете загрузить. Т.о. вы всегда сможете определить наличие\отсутствие нужных DLL файлов и при необходимости - загрузить их.

Сообщение от Дима_ как я лиспом буду его в UTF8 рожать (да да в лиспе принято ресурсы создавать непосредственно программой в зависимоти от "внешних" условий)?

Кого "его"? XAML файл? А зачем его из лиспа "рожать"? Почему его не делать вручную в графическом редакторе или в том же Notepad++? Кроме того, если уж приспичило программно создавать XAML из LISP, но при этом у AutoLISP\Visual LISP существуют проблемы по работе с текстом в кодировке UTF-8 (если я Вас правильно понял), то что мешает написать на .NET/ObjectARX/e.t.c. набор LISP функций, которые снимают эту проблему?

Сообщение от Дима_ да да в лиспе принято ресурсы создавать непосредственно программой в зависимоти от "внешних" условий

В WPF это автоматически решается иным способом: за счёт шаблонов и привязок. Т.е. например, в зависимости от того, какие данные я передам в окно, оно само сгенерирует нужное количество чекбоксов, вкладок, и т.д. Т.е. не нужно код писать для этого.

Сообщение от Дима_ Если пишется функция под лисп - то ИХМО она должна играть по его правилам, иначе зачем она нужна, по императивным правилам можно и нужно писать на том же C# (в том числе и под автокад естественно).

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

Я согласен с тем, что материал мною изложен не самым наглядным\удобным способом, и примеры пожалуй далеко не самые лучшие, но... Хорошо излагать - это уметь нужно.

[Дима_]

Сообщение от hwd то что мешает написать на .NET/ObjectARX/e.t.c. набор LISP функций, которые снимают эту проблему?

Я про это и пишу - чтоб сгенерировать диалог надо написать еще пяток функций.

Сообщение от hwd Решая на .NET задачи для LISP, не нужно пытаться в .net коде реализовать логику лиспа - это неправильно. В решении задачи нужно использовать "родные" средства платформы, а для этого их нужно знать. Тогда и написание кода сведётся к минимуму...

Стоп, если мы делаем для лиспа, а в примере мы рассматриваем именно его, то делать надо естественно не как у родных средств плафтормы, а как это принято в концепции лиспа. Еще раз про аналогию в Interop. Вы, из под .Net (да и не только Вы, что абсолютно логично) будете использовать ее только в случае если ничего другого нет, и ровно до тех пор, пока Микрософт или, еще кто, не сделает вам "нормальную" .Net обертку (или свою функцию - не суть) из управляемого кода. WPF (да и WinForms) - никак не "бъется" с концепцией лиспа они написанны для другой прагмиды программирования (ориентированной на "чистоту" кода (это функциональный термин, а не оскорбление), немутабельность и пр.) и простым вызовом из лиспа - они лисповскими не становятся - чтобы оно работало по его правилам - надо делать свою GUI концепцию (ну наверно не раз Видели примеры диалогов от ShaggyDoc'а) - вот они (хоть и понынешним меркам не красивы и не современны) заточенны под лисп - и с ними код действительно прост и компактен -один минус они затрагивают только его надобность (ну или он "подтянул надобность" под них) - то есть их по простому мало, где в Вашем случае "написание кода сведётся к минимуму"?? DCL ругают не за то, что его вид устарел, а за то, что он "сидит как у коровы седло". Не нужны в лиспе императивно заточенные функции "под платформу" - писать на них можно (и нужно) и так в более чем кучи языков, специально для этого предназначенных.
Offtop: з.ы. уж не знаю доделаю-ли я свою затейку по интеграции .Net как такового в AutoLisp, частично она у меня есть и кое-где используется, но еще сыра и по этому не выкладываю, не в том виде как это сделанно с ActiveX (добавлением вызова методов и свойств) - это не интересно, а нормально с парсингом лисп выражения - преобразованием его в код аналогичный vla...+ замыкания (ну пока реализовал их только в упрощенной форме) + обработкой событий (с навеской на них лисп кода), автоматическим преобразованием созданных классов в замкнутые функции и пр. плюшками - тупо завален делами - руки не доходят, да и когда сделаю боюсь вид далеко уползет от первоначального ибо уже пару раз неслабо "перекручивал".
p/s/s/ Еще раз естественно как функция написанна внутри на .Net - никому не важно, но внешне она должна по критериям биться с функциональными принципами (в нем нет внешних данных), результат должен быть зависим только от аргумента(ов) - не соблюдение этого и есть основной гемор DCL (используются файлы) - Вы предлагаете тоже самое, но "покрасивше" - работать будет, но с остальной программой возникнут косяки - т.к. если мы принимаем возможность изменения файла, надо всегда следить что в нем (соответственно нельзя вызвать в любой момент, использовать рекурсивно (конечно можно - но количество проверок превысит кол-во кода), и пр. "прелести" из-за которых был придуман функциональный подход).

[hwd]

Сообщение от Дима_ то делать надо естественно не как у родных средств плафтормы, а как это принято в концепции лиспа.

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

Сообщение от Дима_ где в Вашем случае "написание кода сведётся к минимуму"??

Я не пишу, что в случае использования WPF или .NET вообще, объём кода будет меньше чем у LISP или DCL. Наоборот - насколько я могу судить, зачастую LISP более компактен в плане написания кода. Однако я отдаю предпочтение большему объёму кода в пользу возможностей и ясности, т.е. хоть XAML разметка и занимает больше места, но она более гибка и порой более читабельна, чем DCL (на мой взгляд).

Устал... В общем я постарался показать, как аналогичные вещи можно делать в .NET, воспользовавшись этим из AutoLISP\Visual LISP. Демонстрация оказалась не самой удачной, но общую картину понять, как мне кажется, всё же можно... Надо оно ему или нет - каждый пусть решает для себя сам...

[alex8888]

hwd, что то у меня оба окошка SelectItemsWindow2.xaml и SelectItemsWindow.xaml выглядят одинаково . В твоем примере 1 у обоих окон код, похоже, один и тот же, как у окна 1.

[hwd]

Сообщение от alex8888 hwd, что то у меня оба окошка SelectItemsWindow2.xaml и SelectItemsWindow.xaml выглядят одинаково . В твоем примере 1 у обоих окон код, похоже, один и тот же, как у окна 1.

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

[alex8888]

Сообщение от hwd Ага вижу, значит я скопировал один и тот же код разметки. Вечером приду домой - исправлю на нужный. Спасибо за замечание.

Это тебе спасибо за попытку научить таких как я

У меня стоит Визуал-Экспресс, поэтому кое-чего не совсем совпадает с твоими примерами. Например, я не могу указать путь для создания и сохранения проекта - открыто только окно как назвать проект и все. Куда он сохраняется - одному лишь Виндоузу известно. Я нашел где то глубоко в каталогах пользователь-документы-...-... ну и так далее (ниже указано где, поточнее ). Или у меня все по-русски, все свойства - пришлось самому думать какие и как перевести .

Другой проблемой пишет: "Не удалось найти имя типа или пространства имен "Autodesk" (пропущена директива using или ссылка на сборку?) C:\Users\at.BUNDH.000\AppData\Local\Temporary Projects\test_dialog1\SelectItemsWindow.xaml.cs"
Как в экспресс указать ссылки на библиотеки автогада? "Обозреватель решения->ссылки->" а дальше куда? Помню, там надо 2 файла acdbmgd.dll и acmgd.dll.
Это нашел куда.
Только теперь конфликт версий фреймворка встал: "не удалось разрешить указанную ссылкой сборку "acmgd", поскольку она зависит от "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", отсутствующей в текущей целевой платформе ".NETFramework,Version=v4.0,Profile=Client". Удалите ссылки на сборки не в целевой платформе или рассмотрите возможность переориентации проекта". Где покопаться?

[hwd]

Сообщение от alex8888 спасибо за попытку научить

я и не пытался научить, просто хотел показать для наглядности, т.е. своего рода это как информация для размышления, не более.

У меня сейчас нет Express версии, поэтому не могу что-либо посмотреть. Если хочешь попасть в каталог, в котором хранятся файлы проекта, то кликни правой кнопкой мышки на имени проекта в окне Solution Explorer и выбери пункт контекстного меню Open Folder in File Explorer.

"Не удалось найти имя типа или пространства имен "Autodesk" (пропущена директива using или ссылка на сборку?)

Правильно пишет. Тебе сначала нужно скачать и установить ObjectARX SDK (просто скачать, и распаковать архив). Старые версии здесь, новые тут. На библиотеки этого SDK и нужно ссылаться (зависит от весии автокада, а так же от того, какие именно из тех библиотек нужны для твоего плагина).

Можешь вкратце напомнить склеротику ? Если не лень, конечно.

Смотри здесь.

[alex8888]

Установил SDK, перенес проект куда надо, указал библиотеки. Но если указываю версию фреймворка 3.5, то пишет ошибку:

"Не удалось разрешить сборку System.Xaml. Целевая инфраструктура, требуемая этой сборкой (4.0), имеет более высокую версию, чем целевая инфраструктура проекта. Если эта ссылка необходима для кода, при компиляции могут возникнуть ошибки"

а если версию 4.0, то:

"не удалось разрешить указанную ссылкой сборку "AcMgd", поскольку она зависит от "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", отсутствующей в текущей целевой платформе ".NETFramework,Version=v4.0,Profile=Client". Удалите ссылки на сборки не в целевой платформе или рассмотрите возможность переориентации проекта"

И как быть в этом случае?

[hwd]

разные версии автокада используют разные версии фрэймворка. Ты под какую версию автокада-то хоть пишешь?

[alex8888]

Не пишу, но хотелось бы.
Автокад Механикал 2011 64х.
Виндоза 7 про.

Offtop: И хочу лишь научиться лепить окошки для своих лиспов, а то DCL обхаяли, да и не все им получается как хотелось бы. То есть тема как бы нужная для меня. Но проблема не столько во времени, (которого как всегда нету), сколько в том, что никак не пойму (ну как тот жираф, что ли), как подступиться к ее решению. Консольные приложения клепать начал, кое-какие успешно использую в работе. Но они никак не связаны с кадом. И "связать" (знаю, ты прикалываешься над моим термином, хотя другого я и не представляю) кад и шарп или .нет не выходит. На первой же ошибке настроение ковыряться дальше стремительно летит к нулю. Даже сила воли не помогает.

[hwd]

если я не ошибаюсь, 2011-й не использует .net 4.0, а значит тебе нужно юзать .net 3.5. Кликни правой кнопкой мыши на имени твоего проекта и выбери пункт Properties. Перейди на вкладку Application и в раскрывающемся списке Target Framework выбери версию 3.5.

[alex8888]

Да, все верно, поэтому я и указывал версию фреймворка 3.5
Но тогда как писал выше, "не удается разрешить сборку System.XAML", потому что ей надо 4.0 версию. Значит ли это, что твои примеры у меня не пойдут?

Тупо удалил конфликтующие ссылки. Количество ошибок уменьшилось до 2-х!
1.

Элемент "InitializeComponent" не существует в текущем контексте. D:\Meine Daten\AT-CAD\C#\test\test_dialog1\test_dialog1\SelectItemsWindow2.xaml.cs

2.

Ни одна из перегрузок метода "Combine" не принимает "3" аргументов D:\Meine Daten\AT-CAD\C#\test\test_dialog1\test_dialog1\SelectItemsWindow.xaml.cs

Тьфу, собак рылась рядом - нужно пути было правильно прописать! Все, ошибки убрал. Спасибо за терпимость.

[hwd]

Сообщение от alex8888 Значит ли это, что твои примеры у меня не пойдут?

Нет, не значит. Вечером из дома выложу тебе вариант того проекта, настроенного на AutoCAD 2011 (на вирт машинке у меня, к твоему счастью, установлены версии 2009-2013) - можешь посмотреть его и сравнить с тем, что ты там самостоятельно наваял.

UPD
Значит так... Флэшка, на которой я это дело сохранил накрылась медным тазом - пришлось её выбросить, а проект восстановить по исходникам, опубликованным мною в блоге... Внёс в XAML разметку небольшие изменения (убрал в первых двух XAML файлах атрибут x:FieldModifier="public", поскольку в первом примере он не нужен для парсинга XAML). Там же выложил и исходник проекта, собранный в MS Visual Studio 2012 для AutoCAD 2013. Проект без проблем открывается и в MS Visual Studio 2010.

Поскольку у тебя AutoCAD 2011, то чтобы ты мне сильно не конопатил мозг обилием вопросов в стиле "аля как переназначить ссылки для AutoCAD 2011 и т.д." - я собрал тебе отдельный вариант этого проекта под AutoCAD 2011 (обычный, т.к. Механикл у меня нет) - смотри вложенный файл ниже в этом сообщении. Единственное, что от тебя потребуется - указать в настройках проекта путь к твоему файлу acad.exe (см. скрин ниже). Надеюсь с этим ты справишься



Для запуска примеров, после того, как загрузишь библиотеку командой NETLOAD, можешь запускать, к примеру, такие LISP функции:

Код:

[Выделить все]

(bushman:select-items-window '("SelectItemsWindow.xaml" "Выбор сотрудников" "Список сотрудников:" "Укажите сотрудников вашего отдела." T) '("Вася" "Петя" "Коля" "Паша" "Маша" "Глаша" "Даша" "Саша"))

(bushman:select-items-window '("SelectItemsWindow2.xaml" "Выбор начальника" "Список сотрудников:" "Укажите начальника вашего отдела." nil) '("Вася" "Петя" "Коля" "Паша" "Маша" "Глаша" "Даша" "Саша"))

(mrX:get-halturka-parameters)