[TwoZero]

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

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

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

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

[V.Khomyakov]

ObjectDCL теперь стал бесплатным и называется OpenDCL http://opendcl.com/wordpress/

[TwoZero]

Уххх.... спасибо щас посмотрю.

[TwoZero]

Установил OpenDCL, посмотрел примеры, протестил в акаде ёёёёууууу это реал тема а главное бесплатно!!!!!!!

Вот ссылочка со скринами (что может эта прога):
http://opendcl.com/wordpress/?page_id=9

[ShaggyDoc]

Поосторожнее с восторгами.

OpenDCL - это дополнительный посредник, причем коварный. Коварство:

1. В основе - ARX, то есть привязка к конкретным версиям AutoCAD и среды разработки. Поменяется в очередной раз сочетание - надо и это менять.

2. Да, стал бесплатный и Open Source. Но это означает, что всё держится на энтузиазме, который быстро иссякает. Конечным потребителям (прикладным разработчикам на ObjectDCL) это может кончиться крахом. Бесплатный сыр.

3. Требуется изучать и саму эту систему.

А какие альтернативы?

1. ObjectARX, в котором можно делать всё. Но, так как интересуют диалоговые окна, есть второй вариант.

2. COM. Это не "VB6 как ActiveX dll", это гораздо шире. VB как раз не лучший вариант, хотя возможно и его использовать, но можно работать вообще в любой среде программирования, поддерживающей COM. Например, Delphi, TurboXXX и что угодно. И если интересует TreeView, то для Delphi есть такие компоненты этого класса, рядом с которыми штатны виндовый нервно курит в сторонке.

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

3. Создание диалога в отдельном приложении (не COM-dll), но так написанном, что пользователь просто этого и не заметит. Для него это просто модальный диалог, вылетающий в нужное время. Писать можно вообще на чем угодно. Не зависит от версий чего бы то ни было.

4. DotNET. Тоже перспектива, так как для AutoCAD уже нет возврата. Сред разработки уже хватает.

Выбор большой, но выбор надо делать правильный.

[V.Khomyakov]

ShaggyDoc Поосторожнее с восторгами

Согласен полностью. OpenDCL я использовал только в одном диалоговом окне, для пробы. Кое что не понравилось. Например: окно сделанное в предыдущей версии OpenDCL и перекомпилированное в новой, работало менее стабильно чем до этого. Остальные окна сделаны на DCL, хотя некоторый функционал всетаки хочется в них добавить.
Присматриваюсь к ObjectARX не только из-за диалоговых окон. Если я правильно понимаю то ObjectARX тоже привязан к ядру AutoCAD. И для каждого ядра требуется свой компилятор и его придется покупать.
Подскажите есть ли бесплатные компиляторы для ObjectARX.

[TwoZero]

На дэльфях сам знаю что есть такие компоненты что даже винда курит,
ибо я програмировал и на Delphi и на СИ и на VBA и на VB6, черт возьми да я даже на бейсик УКН программил, я это прекрасно знаю что можно и на дельфях и на турбоХХХ замутить.

Если потребуется я даж могу проги под акад прям на дельфях писать, и непариться, но я хочу освоить ЛИСП.

Если уж на то пошло, то программить диалоговые окна нужно на ObjectARX он же С++ (Visual Studio). Для профессиональной разработки диалоговых окон круче нет, но даже мне знающему СИ++ тяжело изучать всю эту систему, не все так просто. Я только начал изучать ObjectARX и в дальнейшем собираюсь писать на нем проги под акад.

[Рyslan]

И литературку подскажите по DCL, пожалуйста. Книги выходили по DCL?

[V.Khomyakov]

И литературку подскажите по DCL, пожалуйста. Книги выходили по DCL?

Я пользуюсь книгой Н.Полещук, П.Лоскутов "AutoLISP и VisualLISP в среде AutoCAD", в ней есть глава про DCL.

[TwoZero]

Сообщение от Рyslan И литературку подскажите по DCL, пожалуйста. Книги выходили по DCL?

Книга:
AutoCAD разработка приложений, настройка и адаптация.
Полещук Николай Николаевич

[ShaggyDoc]

программить диалоговые окна нужно на ObjectARX

Ошибочка. Не "нужно", а можно. Только для диалоговых окон ObjectARX - пушка по воробьям. У него гораздо большие возможности, не реализуемые в других системах. Только нужны ли они для конкретной работы? Намерение изучить ObjectARX правильное, но если уже есть опыт работы в других средах, то диалоги можно делать и там. Изучая ObjectARX (с годик) тем более незачем разводиться на ObjectDCL. Время на изучение OA будет потрачено с большей пользой.

Кстати, хоть OA и круче всех, но подобного VirtualTreeView в нем не найдете. Хотя, конечно, теоретически на C++ можно сделать всё. Только у одних можно, а у других уже сделано.

[TwoZero]

Сообщение от ShaggyDoc Только для диалоговых окон ObjectARX - пушка по воробьям.

С этим я полностью согласен, OA незаменимая вещь при разработке сложных интерфейсов и программ, хотя.... впринцепе сложные программы можно написать и на самом лиспе да и интерфейс на DCL можно построить от которого у всех будет башню сносить.

Но все же одно можно сказать точно OA-ом обычно пользуются профессионалы потому что разработка программ на OA требует хороших знаний самого c++, дапустим разработка MFC приложений (это непросто оконные приложения типа Windows Form Application а нечто другое).

[Рyslan]

Такая книга у меня есть, а других книг по DCL нет?

[TwoZero]

Сообщение от Рyslan Такая книга у меня есть, а других книг по DCL нет?

В яндексе забей запрос, на некоторых сайтах инфа есть по DCL

[ShaggyDoc]

OA незаменимая вещь при разработке сложных интерфейсов и программ

Опять ошибочка. ObjectARX - система библиотек, заточенных под AutoCAD. К интерфейсу пользователя и его сложности это имеет слабое отношение. И к сложности программ - понятию очень относительному. Суперсложную, по меркам DOS, программу, например для работы с клиент-серверной базой данных, можно сейчас легко сделать в любой приличной среде программирования.

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

И даже приложение ARX можно написать без ObjectARX и вообще без MS C++. Это всего-лишь DLL с расширением ARX и тремя специальными обязательными функциями. Только в AutoCAD 15 и более поздних такой ARX не выполнить, так как MS и Autodesk сговорились "пущать" только приложения, выполненные в средах разработки Microsoft. А вот для R14 делали ARX прямо в Delphi. Конечно такой ARX не мог использовать возможностей библиотек OA, но вот MFC, любые диалоги или использование WinAPI - пожалуйста.

Вот что действительно можно сделать только в ObjectARX:

а) Создание собственных объектов, а не только стандартных примитивов AutoCAD. Например, объект PIPE со своими свойствами (диаметр, стенка, длина и т.д.)

б) Доступ к таким кишочкам Автокада, куда не добраться средствами COM или штатных функций LISP.

в) Создание доступных в LISP функций, использующих возможности а) и б).

[VVA]

Сообщение от Рyslan Такая книга у меня есть, а других книг по DCL нет?

http://web2.airmail.net/terrycad/Tut.../MyDialogs.htm
http://www.jefferypsanders.com/autolisp_DCL.html
http://www.levins.land.ru/index.html

[Рyslan]

2 сайта на английском. на третьем я все скачал.

[MCAD]

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

Прошу прощения, ошибочка с формой вышла :-(

[TwoZero]

Сообщение от ShaggyDoc Опять ошибочка. ObjectARX - система библиотек, заточенных под AutoCAD. К интерфейсу пользователя и его сложности это имеет слабое отношение. И к сложности программ - понятию очень относительному. Суперсложную, по меркам DOS, программу, например для работы с клиент-серверной базой данных, можно сейчас легко сделать в любой приличной среде программирования. Сложный интерфейс можно легко сделать, имея разработанные кем-то наворочанные визуальные компоненты. В OA их как раз нет. И даже приложение ARX можно написать без ObjectARX и вообще без MS C++. Это всего-лишь DLL с расширением ARX и тремя специальными обязательными функциями. Только в AutoCAD 15 и более поздних такой ARX не выполнить, так как MS и Autodesk сговорились "пущать" только приложения, выполненные в средах разработки Microsoft. А вот для R14 делали ARX прямо в Delphi. Конечно такой ARX не мог использовать возможностей библиотек OA, но вот MFC, любые диалоги или использование WinAPI - пожалуйста. Вот что действительно можно сделать только в ObjectARX: а) Создание собственных объектов, а не только стандартных примитивов AutoCAD. Например, объект PIPE со своими свойствами (диаметр, стенка, длина и т.д.) б) Доступ к таким кишочкам Автокада, куда не добраться средствами COM или штатных функций LISP. в) Создание доступных в LISP функций, использующих возможности а) и б).

Ясно. Походу щас ObjectARX заточен чисто под Микрософт и конкретнее под MS VS C++. терь все ясно

[ShaggyDoc]

А когда-то приложения к AutoCAD можно было делать с любой средой программирования на C++. Мы Borland C++ 2 использовали. А потом они сговорились. Причем очень подло. Одна из обязательных функций в ARX должна возвращать номер версии в виде числа 14, 15, 16 и т.д - по версии Автокада. Это резонно. Но если напишешь свою такую функцию, то выяснится, что работать не будет. Что-то контроль версии делает побочное, разумеется, недокументированное. И не пускает "собак и китайцев".

Вот поэтому я и использую только COM, так как custom-объекты мне не нужны.

[Supermax]

Еще диалоговые окна можно делать на HTML, HTA, HTM и т.п. и на Advanced Script Host. Все чудненько запихивается в FAS (если надо).

[V.Khomyakov]

Еще диалоговые окна можно делать на HTML, HTA, HTM и т.п. и на Advanced Script Host. Все чудненько запихивается в FAS (если надо).

Надо, надо.
Ссылочку, если можно, дайте:-)

[Makswell]

Мне это тоже интересно.
Supermax, не обойди вниманием...

[Кулик Алексей aka kpblc]

V.Khomyakov, Makswell, поищите по словам "веб-макрос"

[Supermax]

Вот ссылка:
http://forum.dwg.ru/showpost.php?p=266764&postcount=13

Про Advanced Script Host я выложил 8.0, но уже вышла 8.2 версия и эта штука условно-бесплатная 10$ стоит, но как это купить? Там с карточками как-то крутят. Если кто-то скачает новую версию и расскажет мне как ее купить - буду очень признателен.

[Supermax]

Очень сильно интересуюсь кто и что видит вот по этой ссылке:
http://www.shareup.com/getfile.php?v...t%2Fdialog.exe

[Кулик Алексей aka kpblc]

Страница удалена как устаревшая

[Supermax]

Она не удалена, это вирус ее переадресовывает. Только вот где он сидит? Все ссылки на скачку Advanced Script Host по всем сайтам переадресовываются на эту гадость. Как это обойти? Может через Америку поискать7

[Supermax]

Натравил Касперских енд компани, может и починят. Три дня тому назад все ссылки работали.

[Supermax]

Как я понимаю, про диалоговые окна диалог закончен?

[Supermax]

Новость дня. Выложенная мною прога Advanced Script Host 8.0 и успешно скачиваемая в течении недели, вдруг безследно исчезла из Данлоадса.
В сети эту прогу кто-то очень сильно недолюбливает и все скачки ее наглухо закупорены переадресовщиками. И тут вдруг она исчезла.
Может ее прямо в тему выложить?

[E-degtyarev]

Можеть быть кто-то знает как организовать временный выход из диал. окна, вызванного самодельной lisp программой, для панорамирования и зуммирования чертежа, чтобы при этом окно оставалось видимым.

[zenon]

Сообщение от Supermax Новость дня. Выложенная мною прога Advanced Script Host 8.0 и успешно скачиваемая в течении недели, вдруг безследно исчезла из Данлоадса. В сети эту прогу кто-то очень сильно недолюбливает и все скачки ее наглухо закупорены переадресовщиками. И тут вдруг она исчезла. Может ее прямо в тему выложить?

не оно?? link

[Disney]

И всё таки. Есть ли варианты?
При написании программы(AutoLISP) с диалогом(DCL), почти половина времени уходит на создание(описание) диалога, даже больше на его оформление, элементы почти всегда игнорируют заданное им выравнивание, приходится space-ами их выравнивать врукопашную, ну и прочие неудобства.
Постоянно читаю подобные темы, вижу что вроде чего-то советуют, вроде там не сложно ..., на том языке можно ..., но кроме AutoLISP больше ни чего не видел и не знаю, даже не знаю к чему и с какого края подступиться.
Есть тема Научите лиспу на примере (или как kpblc, VVA и компания пытаются обучить чайника лиспу), так можно в этой, так же для чайников, научите создавать диалоги не DCL, но для AutoLISP. Или если решил двигаться дальше DCL, то и AutoLISP хоронить?
Хотел придумать какой нибудь простой пример LISP + DCL, но так ни чего коротенького и простого на ум не приходит, сразу начинается куча проверок на корректность ввода данных в диалоге, сразу охота поставить зависимость одних элементов, от введенного значения других, ...
Может уже у кого есть простенькая связка LISP + неDCLдиалог для разбора?

[hwd]

Сообщение от Disney Может уже у кого есть простенькая связка LISP + неDCLдиалог для разбора?

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

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

Сообщение от hwd Полагаю, что и диалоговые окошки можно прикрутить аналогично.

Конечно. И соответственно Disney придётся изучить один из .NET языков.

Disney, здесь целая ветка форума посвящена OpenDCL: http://www.theswamp.org/index.php?board=63.0

[Disney]

Сообщение от Александр Ривилис Конечно. И соответственно Disney придётся изучить один из .NET языков.

и какой из?

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

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

Сообщение от Disney и какой из?

Это на твоё усмотрение. Что ближе C#, VB.NET, F# и еще какие-то...

[Disney]

Сообщение от Александр Ривилис Это на твоё усмотрение. Что ближе C#, VB.NET, F# и еще какие-то...

Да я чую, мне всё далеко...

[hwd]

Сообщение от Disney Пожалуйста, можно для тупых, маленький примерчик, чтоб я хоть чуть-чуть зацепился, и либо стал изучать, либо отказался от этой идеи, изучать неизвестный язык тупо из любопытства очень сложно.

Ок, напишу.

[ShaggyDoc]

Последний диалог на DCL я написал 20.12.2003. Да и то смеха ради. Хотя некоторые подходят очень тщательно, например, был такой "Леха", у которого огромный диалог так был вылизан space-ами, что был "как настоящий". Правда он только один диалог и сделал, потом вообще от AutoCAD отошел.

В LISP надо использовать его преимущества и избегать недостатков. Главный из них - убогий DCL.

Я лично делаю диалоги в виде COM-серверов. У меня всего их 19 шт на пару тысяч LISP-программ. Причем 17 из них используются и в других моих программах, вообще не связанных с AutoCAD. И все их более 4 лет уже не трогал.

Диалоги можно делать и в ObjectARX (но зачем тогда только диалоги?). Но здесь давно отбила охотку совместная "стратегия" MS и Autodesk - привязка версий AutoCAD и VS. Т.е. постоянно следить за контролем версий у себя и всех пользователей.

Можно и на .NET. И связывать судьбу своей "вшивенькой" по объему программы с очередной гонкой обновлений .NET. Пусть уж этим занимаются те, кто пока самые умные (про "пока" они пока не знают). Нам, старым дуракам, пока COM хватает. В обозримом будущем Microsoft от этой технологии не откажется.

Кстати, COM-диалог в Delphi сделать лишь немного посложнее, чем Hello Word. Да и в любой нормальной среде программирования.

[Disney]

Сообщение от ShaggyDoc Кстати, COM-диалог в Delphi сделать лишь немного посложнее, чем Hello Word.

Я кстати в Delphi писал свою выпускную программу в лицеи, но было это аж 15 лет назад, и ни о каком COM я не в курсе.

[Дима_]

У COM сервера "беда" в том, что его тоже надо регистрировать (хотя "приличная" программа на автолиспе все-равно требует установки), и из-за этого я пару раз писал диалоги для автолиспа в виде простого exe - передавал аргументы, кстати, не параметрами - а цеплялся к "активному" автокаду - в общем "тоже вариант".

[gomer]

Сообщение от Disney При написании программы(AutoLISP) с диалогом(DCL), почти половина времени уходит на создание(описание) диалога, даже больше на его оформление, элементы почти всегда игнорируют заданное им выравнивание, приходится space-ами их выравнивать врукопашную, ну и прочие неудобства.

пробелами практически не пользуюсь. Покажите свои проблемные диалоги, может можно их организовать получше

[ShaggyDoc]

я пару раз писал диалоги для автолиспа в виде простого exe - передавал аргументы, кстати, не параметрами - а цеплялся к "активному" автокаду - в общем "тоже вариант".

Да, и вполне нормальный. А уж передать аргументы можно разными способами (реестр, файл). Можно и к Автокаду прицепиться, но это уже сложнее.
Есть хороший способ - передавать такой программе только один параметр - имя INI-файла. А уж там могут быть какие угодно аргументы, в том числе записанные из Lisp. Туда же и результаты записываются. Очень удобно для больших "диалогов", например расчетных программ, по результатам работы которых надо что-то сделать в Автокаде, причем в разных функциях.

[Disney]

Сообщение от gomer Покажите свои проблемные диалоги, может можно их организовать получше

Да, как таковых проблем то нет.
Есть неудобство, например картинки по пикселям рисовать

Зато потом научился

Или вот

Но так извращаться в наше время, как-то мне кажется глупо.

Offtop: Почему закрыли доступ к загрузке картинок через Радикал?
Охота картинки прям по тексту вставлять, а так получается и в тексте и ещё раз в низу в миниатюрах дублируются, особенно GIF не прилично мелькают

[ShaggyDoc]

Зато потом научился

За время, потраченное на один диалог, можно было научиться делать нормальные диалоги.

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

1. Например, любая программа должна рисовать так, как задано в AutoCAD - слой, цвет, тип линии и прочее - текущими настройками, а не индивидуальными настройками каждой программы.

Хочешь откос на каком-то "откосном" слое? Так установи предварительно этот слой. Причем, желательно, из классификатора (справочника) слоев, в котором есть и точное название и цвет и всё прочее. Для топографии это особенно важно. Её часто приходится сводить, и если в каждой шараге будут свои слои, то ничего хорошего не будет.

2. А зачем в диалоге столько "технологических" настроек (шаг, недовод и прочее)? Это всё должно делаться по стандартным правилам. В 99% так и должно быть, а для редких случаев может быть опция во время рисования. Фактически нужно выбрать только тип рисунка откоса, их есть несколько стандартных, и, для любителей, может быть сколько угодно нестандартных.

Лишние настройки только мешают пользователю, да и время разработчика отнимают.

На прилагаемых скриншотах единый диалог "чего угодно". Он написан один раз, а применяется тысячи раз. Тут и рельеф, и линии, и точечные знаки. Что, для каждого вида рисунка свой диалог сочинять? Так только в топографии более 500 разных УГО, замучаешься. А уж про все виды чертежей и говорить нечего.

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

Само меню (их может быть сколько угодно) описано в XML. Элемент, описывающий окос, выглядит так

Код:

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

  <item name='Откос ТОПО неукрепленный' 
          image='land\topo\relief\ot_pro.png'  
         comment='Откос заданного размера с произвольными бровками' 
         macro='(ru-draw-topo-slope T nil 2.0 1.0)'/>

При выборе в Lisp передается строка, описанная в атрибуте macro и выполняется. А там вызов функции с аргументами. Другое сочетание аргументов даст другое изображение. Работа программиста сводится к написанию правильных функций, а не к возне с DCL.

И еще несколько примеров.

1. Выбор линейных условных знаков и выбор точечных.

2. Простенький диалог с двумя вводами чисел применяется очень часто - там где надо ввести одно или два значения (длина и ширина и т.п.). Можно задать допустимый диапазон, позволить выбрать число из справочника (который, разумеется, будет также в виде древовидного XML), "прочитать" число из AutoCAD, указав на какой-то примитив (текст, атрибут). Такой диалог можно вызвать где угодно. Если надо, так и в рисовании откосов, в качестве опции.

Вызов наподобие

Код:

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

 (ru-dlg-get-two-number  "Размеры пилястры" "Длина вдоль стены"  640  120 1000  "Ширина перпендикулярно стене"  380 120 6000 "common\\options\\ru_wall_width.xml" "common\\options\\ru_wall_width.xml" nil nil)

А ведь для этого можно было взяться писать свой диалог "Рисование пилястр". А потом "Рисование колонн", "Рисование отверстий" и т.д. до бесконечности


3. И, для сравнения, выбор файла. Там много чего отличается от штатных средств Windows. Но этот диалог сделан в виде функции с аргументами наподобие

Код:

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

 (ru-dlg-file-select-dwg   "Файл блока"   (strcat *ru_libs_dir*  "block-lib\\")   (strcat *ru_libs_dir*  "block-lib\\")  t   nil) 

Так что не надо терять время на DCL. Надо освоить какую-нибудь систему программирования. Не VBA, конечно.

[gomer]

Сообщение от Disney Есть неудобство, например картинки по пикселям рисовать

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

Сообщение от ShaggyDoc В него затолканы все мыслимые параметры, включая цвет.

Согласен, рисование откоса слайдами намного проще, а показывать его в цвете - красивость...

Сообщение от Disney Или вот

о, это мохнатый диалог, написанный даже не помню уже кем и когда, но вы добавили красивость, затратив время, кстати не такое уж большое. Имхо, выбирать блоки нужно из списка, а не бродить по дереву
а формировать список можно по разному: жестко-програмно или библиотечно-папочно, тут COM в помощь, все уже написано до нас
кстати диалог откоса мне сразу не понравился, эти рога вверху... неэргономично, насчет слоя согласен с ShaggyDoc (либо текущий, либо из списка, либо определенный программой, создание нового слоя, может привести к к каше
Как итог, такой диалог пишется, ну, 10 мин макс, с тестированием

[ShaggyDoc]

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

Можно и деревья каменным топором рубить.
Где слайды рисуются "быстрее"? На экране, что ли? Не смешите. А сколько надо телодвижений, чтобы создать слайд (да ещё правильно отображиющийся), да создать библиотеку. И ради чего, ради убогого DCL (а больше никому sld не нужен). А растровую картинку мы получаем одним щелчком (левая нижняя кнопка). Картинка прямо с экрана нужного размера вырезается, сохраняется в нужное место и сама показывается.

Имхо, выбирать блоки нужно из списка, а не бродить по дереву

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

[gomer]

Сообщение от ShaggyDoc Ну-ка, выберите из линейного списка 500 условных знаков нужный.

Сколько разных блоков ваши пользователи используют за час. день, месяц, год?
Согласен, в автокаде dcl убогий, в брикскаде, например, нет проблемы с пробелами, нет проблемы со слайдами, улучшено отображение табулированных списков, директива include работает как надо и т.д., а слайд делается очень просто, без всяких вырезаний, с помощью простого лиспа
Почему я против деревьев? Например многие пользователи любят формальности, да так, что, чтоб найти нужный файл, нужно войти аж в:
сервер/гипство/завод/цеха/цех/год/проект/конструкции... или даже глубже...

[ShaggyDoc]

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

Не "блоков", а пунктов меню. Блок - частный, самый примитивный случай. Всего пунктов - около 15 тыс. Конкретный пользователь, например, топограф использует каждую минуту около десятка пунктов меню. Иногда больше, если что -то простое, наподобие столбов или деревьев. Но этот десяток ему надо выбирать из сотни, а то и больше "элементов списка".

Почему я против деревьев? Например многие пользователи любят формальности, да так, что, чтоб найти нужный файл, нужно войти аж в: сервер/гипство/завод/цеха/цех/год/проект/конструкции.

Это правильные пользователи. Жалко, что "а баба яга против". Ну, свалите всё в корень диска или одного каталога. А вот дело программиста - обеспечить возможность быстрого (в один клик) доступа в нужный каталог. Да еще так, чтобы пользователь мог сам менять приоритеты по необходимости.

Вот, например, в Total Commander есть кнопка[*], которая позволяет запомнить каталог в списке (и так же легко удалить оттуда). Кто умеет работать - постоянно ей пользуются. Кто не умеет - стонет "я против".

Вот так и у меня в ruCAD есть такое "Мое меню", в которое пользователь отбирает то, что именно он, чаще всего использует. Разумеется, тоже в виде дерева. А деревья всегда раскрыты при вызове не предыдущем использованном пункте, потому что вероятность использования однотипных команд (или повтора) гораздо больше. Заодно и все пункты меню имеют легко запоминающиеся цифровые имена команд. Не "ОТКОСГЕОДЕЗИЧЕСКИЙ", а 0030, например. И запоминается легко, и с клавиатуры можно вызвать проще. Сами цифровые имена видны в меню AutoCAD или в хинтах.

[Disney]

Парни спасибо, что поддержали тему, но опять ушли в сторону.
hwd, буду ждать обещанного примера,

Сообщение от ShaggyDoc К тому же их надо делать проще. Взять, например, твой диалог с откосом. В него затолканы все мыслимые параметры, включая цвет. А большинство из них не нужны! Надо использовать штатные средства. 1. Например, любая программа должна рисовать так, как задано в AutoCAD - слой, цвет, тип линии и прочее - текущими настройками, а не индивидуальными настройками каждой программы. Хочешь откос на каком-то "откосном" слое? Так установи предварительно этот слой. Причем, желательно, из классификатора (справочника) слоев, в котором есть и точное название и цвет и всё прочее. Для топографии это особенно важно. Её часто приходится сводить, и если в каждой шараге будут свои слои, то ничего хорошего не будет. 2. А зачем в диалоге столько "технологических" настроек (шаг, недовод и прочее)? Это всё должно делаться по стандартным правилам. В 99% так и должно быть, а для редких случаев может быть опция во время рисования. Фактически нужно выбрать только тип рисунка откоса, их есть несколько стандартных, и, для любителей, может быть сколько угодно нестандартных. Лишние настройки только мешают пользователю, да и время разработчика отнимают.

Ну, программы я пишу не для конкретного предприятия, а как правило для геодезистов мелких предприятий, которые не вкурсе, что есть Geonics или Civil или тупо им их не кто не покупает, и большинство из них больше полевки, чем камеральщики, большинство из них чертят вообще всё в одно слое 0, и представления не имеют о каких-то там настройках системы, и стандартах предприятия. А выбор слоя\цвета это уже тоже своего рода библиотечные функции написанные давно и однажды, так что я на них доп. время не трачу. По началу мои диалоги были тоже скудны и лаконичны, но пользователи всё просили и просили, и сколько я им не объяснял, что например высота текста берётся текущей из сис. переменной TEXTSIZE, и устанваите её пожалуйста за ранее такой как вам нужно, но бесполезно, когда в 20 раз меня попросили сделать ввод высоты текста в диалоге, я сдался и сделал.
Что касается "шага и прочих параметров", нифига это однозначно не определено в нормативах, например:

При больших площадях изображений откосов на топографических планах целесообразно разрежать штриховку их условных знаков в 1,5-2 или 3 раза

Это как тоже автоматически учитывать? "большие площади" это сколько?
или

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

"3 см" Это сколько? 3 ед.чертежа, или 0.03, или 30? А... это на бумаге 3 см, а сколько же это в модели? а в каком масштаб топоплана 1:500 и 1: 5 000, и как чертит пользователь всегда в 1:1 000, а уже оформляет в каком нудно?

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

Сообщение от gomer о, это мохнатый диалог, написанный даже не помню уже кем и когда, но вы добавили красивость, затратив время, кстати не такое уж большое. Имхо, выбирать блоки нужно из списка, а не бродить по дереву а формировать список можно по разному: жестко-програмно или библиотечно-папочно, тут COM в помощь, все уже написано до нас

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

Сообщение от gomer кстати диалог откоса мне сразу не понравился, эти рога вверху... неэргономично

Какие рога?
Вот из-за эргономики меня и достал DCL, чтоб элементы подвинуть\передвинуть\выровнять, столько мороки.

Сообщение от ShaggyDoc Вот так и у меня в ruCAD есть такое "Мое меню", в которое пользователь отбирает то, что именно он, чаще всего использует.

А в моих диалогах, есть запоминание всех последних введённых параметров навсегда, раз настроил, и больше не надо, только вызывай команду и сразу пользуйся.

[hwd]

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

Я делаю несколько вариантов, под разные сценарии работы. Результат выложу в блоге и дам ссылку. Здесь выкладывать не буду, т.к. нет желания.

Можно и на .NET. И связывать судьбу своей "вшивенькой" по объему программы с очередной гонкой обновлений .NET. Пусть уж этим занимаются те, кто пока самые умные (про "пока" они пока не знают). Нам, старым дуракам, пока COM хватает. В обозримом будущем Microsoft от этой технологии не откажется.

Цитата выше - полнейшая ерунда. Вообще-то .NET уже давно является частью операционной системы (для тех кто не в курсе) и постоянно развивается. Под "развитием" подразумевается наращивание функционала, который уже и без того недетский. COM хорошая технология. Из любопытства я когда-то создавал в ней свои компоненты, регистрировал их и юзал (учился по книге Дейла Роджерсона "Основы COM"). Однако в отношении графического интерфейса COM всегда будет далеко отставать от того же WPF как в плане лёгкости, скорости разработки, так и в плане возможностей, красоты. Лично мне не нравятся те картинки, которые выше показывал ShaggyDoc - глядя на них у меня сразу возникает ассоциация с Windows 95. Но это скорее моё субъективное восприятие. Мне импонирует более современный вид GUI, который можно легко создавать с помощью всё того же WPF (хотя я в этом и не мастер в виду скудной фантазии).

@Disney
На тему плюсов/минусов связки .NET + LISP так же отпишусь в блоге.

Сообщение от ShaggyDoc Я тоже не ем устриц, но охотно рассуждаю об их вкусе и способах "схлюпывания".

Как-то у вас это в привычку вошло...

[Do$]

Ну на самом деле, если бы не автоматическое создание кода в Visual Studio, писать диалоги WinForm (и WPF, наверное) было бы не намного легче, чем DCL. Разумеется, возможностей, всяких контролов и пр. красивостей и удобностей в WinForm гораздо больше. И диалоги научиться делать в VS довольно несложно, особенно после хорошей практики в DCL. Правда, для меня пока полная загадка, будут ли они работать в других автокадах/виндовсах, кроме тех версий, под которые я их напишу

[hwd]

Сообщение от Do$ если бы не автоматическое создание кода в Visual Studio, писать диалоги WinForm (и WPF, наверное)

Выделенное абсолютно не верно. Ты можешь легко (в смысле, что это очень просто) создавать любой сложности GUI, не написав ни одной строчки программного кода, и при этом вообще не пользуясь MS Visual Studio. Сложность GUI ограничивается лишь твоей фантазией (2D/3D интерфейсы любой сложности). Временами для этого я использую обычный Notepad++.
WinForms - это всего лишь управляемая оболочка над функциями WinAPI, создающими GUI. Для прорисовки используется ЦП.
WPF полностью самостоятельна, для прорисовки используется DirectX и видеокарта. Преимущества WPF не заканчиваются на мощной графике. Очень грамотно реализована идея привязок. Само приложение делится на три части: модель (собственно объектная модель, для работы с которой создаём GUI), представление (сам GUI) и модель представления (связующее звено, между моделью и представлением). За счёт такой структуры любое звено можно заменить другой реализацией, без каких либо изменений/последствий в проекте. Этот паттерн известен как MVVM.

Сообщение от Do$ для меня пока полная загадка, будут ли они работать в других автокадах/виндовсах, кроме тех версий, под которые я их напишу

Версия ОС не имеет значения: XP, Vista, 7, 8.
Компилировать .NET код можно для платформ x86, x64 или AnyCPU. Последний вариант создаёт код, независимый от разрядности ОС. Первые два следует использовать в том случае, если в .NET коде используются сторонние библиотеки, зависящие от разрядности платформы (как правило это не .NET библиотеки).

Под каждую новую версию AutoCAD, .NET код нужно компилировать отдельно, что обусловлено реализацией .NET API компанией Autodesk. Неприятно, но не смертельно, ибо занимает немного времени, как правило - 3-5 секунд на решение, в котором находится десяток проектов. Неприятная необходимость компилирования под каждую версию AutoCAD с лихвой компенсируется возможностями, которые разработчику предоставляет .NET - это далеко не только построение GUI, но и решение любых задач, с которыми неудобно\невозможно возиться в LISP...

Ограничение WPF: эта технология реализована только под Windows. Реализации для MAC OS и Linux отсутствуют в виду того, что реализация требует много усилий.

[ShaggyDoc]

Вообще-то .NET уже давно является частью операционной системы (для тех кто не в курсе) и постоянно развивается.

Ню-ню. То-то каждая вшивенькая программа заставляет устанавливать очередную версию .NET. Скоро будут заставлять устанавливать очередную версию Windows. И часто только из-за того, что "импонирует более современный вид".

Да вид-то проще всего установить - хоть в каком стиле, хоть "линуксовый", хоть Win8, хоть какой.

[hwd]

Сообщение от ShaggyDoc Ню-ню. То-то каждая вшивенькая программа заставляет устанавливать очередную версию .NET. Скоро будут заставлять устанавливать очередную версию Windows. И часто только из-за того, что "импонирует более современный вид".

Хм... Вообще-то, подобного рода "заявлениями" вы существенно понижаете свою "карму", странно, что вы этого не понимаете... Берите пример с Александра Ривилиса - он весьма осторожен в высказываниях

Любая программа для своей работы имеет определённые системные требования. .NET разработчик волен компилировать один и тот же код под разные версии .NET Framework, чтобы клиент мог воспользоваться той версией, которая соответствует установленной у него платформой. Более того, зачастую нужные версии уже присутствуют на компьютере. Актуальный версий, которые могут потребоваться, не так уж и много: 3.5, 4.0 и 4.5. Компания Microsoft, в отличие от компании Autodesk, к счастью пока не грешит ежегодным выпуском своих продуктов, в погоне за планом ежегодных продаж. .NET Framework - бесплатная платформа, поэтому версий .NET гораздо меньше, чем версий AutoCAD.

Сообщение от ShaggyDoc Да вид-то проще всего установить - хоть в каком стиле, хоть "линуксовый", хоть Win8, хоть какой.

Не мешайте мух с котлетами... Представления, шаблоны и стили - это "четыре совершенно разных человека"! Всё это грамотно реализовано в WPF.

[Do$]

Весьма полезная информация! Спасибо!

Сообщение от hwd Неприятная необходимость компилирования под каждую версию AutoCAD с лихвой компенсируется возможностями, которые разработчику предоставляет .NET - это далеко не только построение GUI, но и решение любых задач, с которыми неудобно\невозможно возиться в LISP...

Я думаю, что у многих LISP-программистов мысли об изучении чего-то еще, в том числе и .NET приходят именно из-за написания диалогов

Сообщение от hwd Компилировать .NET код можно для платформ x86, x64 или AnyCPU. Последний вариант создаёт код, независимый от разрядности ОС. Первые два следует использовать в том случае, если в .NET коде используются сторонние библиотеки, зависящие от разрядности платформы (как правило это не .NET библиотеки).

При таком положении дел, можно писать лисп-программу, а диалог к ней - на .NET (я так понимаю, что не очень принципиально что это будет - WinForm или WPF, учитывая, конечно, что в первом случае - меньше "плюшек"). И тогда можно пользоваться принципом, который озвучил Дима_:

Сообщение от Дима_ и из-за этого я пару раз писал диалоги для автолиспа в виде простого exe - передавал аргументы, кстати, не параметрами - а цеплялся к "активному" автокаду - в общем "тоже вариант".

При этом, как мне думается, проблем с версиями AutoCAD практически не должно быть.

[hwd]

Сообщение от Do$ При таком положении дел, можно писать лисп-программу, а диалог к ней - на .NET (я так понимаю, что не очень принципиально что это будет - WinForm или WPF, учитывая, конечно, что в первом случае - меньше "плюшек").

Совершенно верно.

[Дима_]

Раз уж вспомнили, там проявляется еще "положительный момент", при "должной" проверке на ошибки - окна без проблем делаются не диалоговыми, а "интерактивными" - типа как в моей змейке рубика (там правда нет ни строчки на лиспе, но я про суть "интерактивности") - ИХМО этот подход (при опять-же правильной обработке лиспом) - позволяет сильно облегчить юзеру работу.

[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)

[alex8888]

hwd, спасибо за код.
Один вопросик, возможно из-за этого ты и применяешь полную версию визуал-студии.
Смотри по прилагаемому рисунку из Microsoft Visual Studio 2010 экспресс:

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

Получается, что с этим то как раз и не справился

[hwd]

Сообщение от alex8888 Получается, что с этим то как раз и не справился

Похоже на то... попробуй подключиться к уже запущенному процессу (acad.exe) выбрав в меню такой пункт (если это присутствует в Express версии):



В противном случае, ты наверное сможешь только писать код, компилировать его, но не отлаживать (для плагинов AutoCAD). Т.е. ты можешь скомпилировать код, затем вручную запустить AutoCAD и командой NETLOAD загрузить то, что ты скомпилировал. Например в подкаталоге DEBUG уже имеется версия, которую ты можешь так загрузить и поюзать.

Кстати, вспомнил: у меня в блоге Boxa оставил сообщение о том, что он без проблем пишет плагины в Express версии:

Сообщение от Boxa Проблема только в отладке, но и это решается парой строчек в .vbproj файле проекта

Можешь дёрнуть его за подробностями, я бы тоже с интересом глянул на эти пару строчек (хотя предполагаю, что это то, что я показываю тебе ниже в UPD)...

UPD
я тут подумал как решить твою проблему... Открой в блокноте файл WpfThroughAutoLISP.csproj.user и в нём замени строку C:\Program Files\Autodesk\AutoCAD 2011\acad.exe на свой вариант. Затем попробуй запустить код на исполнение в отладчике...

[alex8888]

В режиме отладки не работает. По твоему совету заменил строку,что указал. При запуске отладчика запускается новый экземпляр Автокада (один уже был запущен до этого, пробовал и без запущенного - та же басня), с кучей ошибок:

Die Anwendung unterstьtzt kein JIT-Debuggen.
Weitere Informationen finden Sie am Ende dieser Meldung.

************** Ausnahmetext **************
System.Windows.Markup.XamlParseException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. Fehler in Objekt "System.Windows.Data.Binding" in Markupdatei "AcWindows;component/AppFrame/acAppFrame.xaml". ---> System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.InvalidProgramException: Die Common Language Runtime hat ein ungьltiges Programm gefunden.
bei Autodesk.AutoCAD.ApplicationServices.Application.get_UIBindings()
--- Ende der internen Ausnahmestapelьberwachung ---
bei System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
bei System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
bei System.Windows.Markup.StaticExtension.ProvideValue(IServiceProvider serviceProvider)
bei System.Windows.Markup.BamlRecordReader.GetStaticExtensionValue(Int16 memberId)
bei System.Windows.Markup.BamlRecordReader.GetExtensionValue(IOptimizedMarkupExtension optimizedMarkupExtensionRecord, String propertyName)
bei System.Windows.Markup.BamlRecordReader.ReadPropertyWithExtensionRecord(BamlPropertyWithExtensionRecord bamlPropertyRecord)
bei System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
--- Ende der internen Ausnahmestapelьberwachung ---
bei System.Windows.Markup.XamlParseException.ThrowException(String message, Exception innerException, Int32 lineNumber, Int32 linePosition, Uri baseUri, XamlObjectIds currentXamlObjectIds, XamlObjectIds contextXamlObjectIds, Type objectType)
bei System.Windows.Markup.XamlParseException.ThrowException(ParserContext parserContext, Int32 lineNumber, Int32 linePosition, String message, Exception innerException)
bei System.Windows.Markup.BamlRecordReader.ReadRecord(BamlRecord bamlRecord)
bei System.Windows.Markup.BamlRecordReader.ReadElement(Int64 startPosition, XamlObjectIds contextXamlObjectIds, Object dictionaryKey)
bei System.Windows.ResourceDictionary.CreateObject(Int32 valuePosition, Object key)
bei System.Windows.ResourceDictionary.RealizeDeferContent(Object key, Object& value, Boolean& canCache)
bei System.Windows.ResourceDictionary.GetValueWithoutLock(Object key, Boolean& canCache)
bei System.Windows.ResourceDictionary.GetValue(Object key, Boolean& canCache)
bei System.Windows.ResourceDictionary.GetValueWithoutLock(Object key, Boolean& canCache)
bei System.Windows.ResourceDictionary.GetValue(Object key, Boolean& canCache)
bei System.Windows.ResourceDictionary.get_Item(Object key)
bei Autodesk.AutoCAD.Internal.Windows.RibbonContent.get_NonZeroDocQAT()
bei Autodesk.AutoCAD.Internal.Windows.RibbonContent.GetNonZeroDocumentQATControl(String sId)
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.LoadQuickAccessToolbarContent(MenuGroupData menuGroupData, Dictionary`2 workspaces, Dictionary`2 quickAccessToolbarItems)
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.LoadContent()
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.RestoreItems()
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.Initialize()
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.LoadQuickAccessToolbar()
bei Autodesk.AutoCAD.Internal.Windows.QuickAccessToolbarService.OnApplicationIdle(Object sender, EventArgs e)
bei System.EventHandler.Invoke(Object sender, EventArgs e)
bei Autodesk.AutoCAD.ApplicationServices.Application.raise_Idle(Object value0, EventArgs value1)
bei Autodesk.AutoCAD.ApplicationServices.Application.OnIdle()


************** Geladene Assemblys **************
mscorlib
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400).
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll.
----------------------------------------
acdbmgd
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.115.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AcdbMgd.DLL.
----------------------------------------
mscorlib.resources
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400).
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll.
----------------------------------------
System
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5466 (Win7SP1GDR.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll.
----------------------------------------
msvcm90
Assembly-Version: 9.0.30729.6161.
Win32-Version: 9.00.30729.6161.
CodeBase: file:///C:/Windows/WinSxS/amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251/msvcm90.dll.
----------------------------------------
System.Xml
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5420 (Win7SP1.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll.
----------------------------------------
System.Drawing
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5462 (Win7SP1GDR.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.
----------------------------------------
PresentationFramework
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.6920.5448 built by: Win7SP1GDR.
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/PresentationFramework/3.0.0.0__31bf3856ad364e35/PresentationFramework.dll.
----------------------------------------
WindowsBase
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.6920.5448 built by: Win7SP1GDR.
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/WindowsBase/3.0.0.0__31bf3856ad364e35/WindowsBase.dll.
----------------------------------------
PresentationCore
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.6920.5448 built by: Win7SP1GDR.
CodeBase: file:///C:/Windows/assembly/GAC_64/PresentationCore/3.0.0.0__31bf3856ad364e35/PresentationCore.dll.
----------------------------------------
System.Configuration
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5420 (Win7SP1.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll.
----------------------------------------
AdApplicationFrame
Assembly-Version: 0.0.0.0.
Win32-Version: 3.0.269.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AdApplicationFrame.DLL.
----------------------------------------
AdWindows
Assembly-Version: 3.0.270.0.
Win32-Version: 3.0.270.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AdWindows.DLL.
----------------------------------------
AdWindows.resources
Assembly-Version: 3.0.263.0.
Win32-Version: 18.1.49.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/de-DE/AdWindows.resources.DLL.
----------------------------------------
PresentationFramework.Aero
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.6920.4902 built by: NetFXw7.
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/PresentationFramework.Aero/3.0.0.0__31bf3856ad364e35/PresentationFramework.Aero.dll.
----------------------------------------
acmgd
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.208.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/acmgd.DLL.
----------------------------------------
System.Core
Assembly-Version: 3.5.0.0.
Win32-Version: 3.5.30729.5420 built by: Win7SP1.
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll.
----------------------------------------
AcWindows
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.208.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AcWindows.DLL.
----------------------------------------
AcWindows.resources
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.49.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/de-DE/AcWindows.resources.DLL.
----------------------------------------
acmgd
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.49.0.0.
CodeBase: file:///D:/Meine%20Daten/AT-CAD/C%23/test/WpfThroughAutoLISP%20for%20Acad%202011/bin/Debug/acmgd.dll.
----------------------------------------
AcCui
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.115.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AcCui.DLL.[/SPOILER]
----------------------------------------
AmMgdInteropReverse
Assembly-Version: 15.0.0.0.
Win32-Version: 15.0.205.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AmMgdInteropReverse.DLL.
----------------------------------------
AmRibbon
Assembly-Version: 14.0.0.0.
Win32-Version: 15.0.205.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AmRibbon.DLL.
----------------------------------------
AmWindows
Assembly-Version: 14.0.0.0.
Win32-Version: 15.0.46.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AmWindows.DLL.
----------------------------------------
AmPartAuthUI
Assembly-Version: 14.0.0.0.
Win32-Version: 15.0.46.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AmPartAuthUI.DLL.
----------------------------------------
System.Windows.Forms
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5460 (Win7SP1GDR.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.
----------------------------------------
AmMgdInterop
Assembly-Version: 15.0.0.0.
Win32-Version: 15.0.46.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AmMgdInterop.DLL.
----------------------------------------
AcMr
Assembly-Version: 18.1.0.0.
Win32-Version: 18.1.49.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/AcMr.DLL.
----------------------------------------
System.Runtime.Serialization
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.4506.5420 (Win7SP1.030729-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Runtime.Serialization/3.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll.
----------------------------------------
AcadLispFunctions
Assembly-Version: 1.0.0.0.
Win32-Version: 1.0.0.0.
CodeBase: file:///D:/Meine%20Daten/AT-CAD/NET/AcadLispFunctions/AcadLispFunctions/bin/Release/AcadLispFunctions.dll.
----------------------------------------
AmWindows.resources
Assembly-Version: 14.0.0.0.
Win32-Version: 15.0.46.0.0.
CodeBase: file:///C:/Program%20Files/Autodesk/ACADM%202011/de-DE/AmWindows.resources.DLL.
----------------------------------------
PresentationFramework.resources
Assembly-Version: 3.0.0.0.
Win32-Version: 3.0.6920.4902 built by: NetFXw7.
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/PresentationFramework.resources/3.0.0.0_de_31bf3856ad364e35/PresentationFramework.resources.dll.
----------------------------------------
System.Windows.Forms.resources
Assembly-Version: 2.0.0.0.
Win32-Version: 2.0.50727.5420 (Win7SP1.050727-5400).
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.
----------------------------------------

************** JIT-Debuggen **************
Die Anwendung unterstьtzt kein JIT-Debuggen fьr Windows Forms.
Weitere Informationen erhalten Sie vom Autor
der Anwendung.

. ---

Но в режиме _netload и тд работает нормально, т.е. проблема заключается в работе с отладкой в экспресс версии

[hwd]

Сообщение от alex8888 Но в режиме _netload и тд работает нормально, т.е. проблема заключается в работе с отладкой в экспресс версии

возможно. мне сложно лечить по фотографии, да и времени для этого нет

[alex8888]

Сообщение от hwd возможно. мне сложно лечить по фотографии, да и времени для этого нет

Жаль, конечно, что ты не экстрасенс , но и того, что ты дал уже достаточно на первое время

Буду дома полную версию насиловать, правда надо будет автокад еще установить для опытов.

В идеале хотелось бы видеть так:
1. из лиспа или просто путем запуска программы без автокада вызывать окно для выбора из справочника или заполнения формы своими данными.
2. при нажатии ОК (упрощенно излагаю) сформированный список передается в лисп или в файл (надо поразмыслить что лучше).
Тогда получится, что окна могут быть и не модальными, что достаточно и экспресс-студии, а о DCL можно будет забыть как о страшном сне.

[Дима_]

Сообщение от alex8888 В идеале хотелось бы видеть так: ...

И в чем проблемма реализации?

[hwd]

Сообщение от alex8888 Тогда получится, что окна могут быть и не модальными

они и так могут быть не модальными, если тебе нужен немодальный вариант вызова... Для этого, в программном коде, вместо метода ShowModalWindow нужно вызывать метод ShowModelessWindow.

В идеале хотелось бы видеть так: 1. из лиспа или просто путем запуска программы без автокада вызывать окно для выбора из справочника или заполнения формы своими данными. 2. при нажатии ОК (упрощенно излагаю) сформированный список передается в лисп или в файл (надо поразмыслить что лучше). Тогда получится, что окна могут быть и не модальными, что достаточно и экспресс-студии, а о DCL можно будет забыть как о страшном сне.

это делается элементарно.

[alex8888]

Сообщение от Дима_ И в чем проблемма реализации?

Пока только в организации процесса:

1. Проблемы экспресс-студии и отладки
2. Не до конца ясен процесс доступа к программам из Автокада (зависит от п.1)
3. Плюс путаница из версий фреймворков и автокадов.
4. Основной: процесс обучения идет не так быстро, как хотелось бы.

А так сама идея понятна.

это делается элементарно

Ну, дойдем и до этого . С лиспом то вроде бы все в порядке (насколько он мне нужен в работе). Научили

[hwd]

Сообщение от alex8888 1. Проблемы экспресс-студии и отладки

Это коммерческая политика компании Microsoft.

Сообщение от alex8888 2. Не до конца ясен процесс доступа к программам из Автокада (зависит от п.1)

Этой фразы я не понял.

Сообщение от alex8888 3. Плюс путаница из версий фреймворков и автокадов.

имхо, никакой путаницы нет: в AutoCAD 2009-2011 можно юзать 3.5, в 2012 - точно не помню, 3.5 или 4.0 (на рабочей машине у меня нет 2012, поэтому глянуть не могу), в 2013-м используется 4.0.

UPD
По крайней мере два мембера (alex8888 и Disney) справились с обозначенными в моём блоге примерами (возможно даже дочитали до конца)... Ну, значит какой-то толк от той заметки всё же имеется...

[alex8888]

Этой фразы я не понял.

А чего тут непонятного? Ну не укладывается у меня пока в голове сам процесс. Все время методом научного тыка получается работать. А хотелось бы просто знать, что за чем и почему. Для этого требуется "немножко время"

Это коммерческая политика компании Microsoft

Это процесс вышибания "бабла" и их тоже можно понять

возможно даже дочитали до конца

Дочитали, дочитали, не сомневайся
Вот только что поняли

[Дима_]

Я не использую отладку в классическом понимании этого слова (скажем так трассировку) там где есть REPL - за ненадобностью (поэтому я и использую в .Net F#). У меня такая-же "честная бесплатная" студия, с настроенной компиляцией во все используемые версии .Net.

Ну, значит какой-то толк от той заметки всё же имеется...

Я хоть и не запускал - но толк 100% в ней есть - у меня расписать хоть, что-то на общее обозрение руки так не разу и не дошли, хотя чужое читаю с удовольствием - даже если и знаю "что к чему" всегда находятся интересные "обороты" которые стоит взять на заметку.

[gomer]

Сообщение от alex8888 проблема заключается в работе с отладкой в экспресс версии

Обожаю вс за бред, который она несет, когда случайно "буквочку" пропустил

[alex8888]

Сообщение от gomer Обожаю вс за бред, который она несет, когда случайно "буквочку" пропустил

Offtop:
Не понял, что за наезд?

[hwd]

Сообщение от alex8888 Не понял, что за наезд?

Не обращай внимание, это всего лишь "большой специалист" в области .net и MSVS.

[gomer]

Сообщение от alex8888 Не понял

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

[hwd]

Сообщение от gomer обожаю тех

ты обожаешь словоблудие

[Boxa]

Оставлю это здесь:
После создания и сохранения проекта в VS2010Ex в файле вида tmp.vbproj будет секция :

Код:

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

...........
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>bin\Debug\</OutputPath>
    <DocumentationFile>tmp.xml</DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
 </PropertyGroup>
...........

Замените ее на :

Код:

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

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
     <Optimize>false</Optimize>
     <WarningLevel>4</WarningLevel>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>bin\Debug\</OutputPath>
     <StartAction>Program</StartAction>
     <StartProgram>C:\Program Files\Autodesk\AutoCAD 2012 - Russian\acad.exe</StartProgram>
    <DocumentationFile>tmp.xml</DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  </PropertyGroup>

<NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn> - набор цифр будет свой

не забудьте правильно прописать путь до acad.exe

в меню Сервис -> Параметры -> постаьте галку "расширенные параметры" появится меню "Построение"

Все готово, можно работать.


в 2012 - официально 4.0 (хотя по недосмотру пару раз запускал и с 3.5 да еще и с библиотеками на 2011 версию и ничего, проглатывал и не морщился...)

В Ex версии нет "attach to process"

[Disney]

Сообщение от Boxa В Ex версии нет "attach to process"

Как же нет?

[Boxa]

Сообщение от Disney Как же нет?

Сообщение 81, на картинке 2010 версия, а там вот так:

[hwd]

т.е. имеется стимул переходить на 2012-й Express с 2010-го.

[alex8888]

Сообщение от hwd т.е. имеется стимул переходить на 2012-й Express с 2010-го.

Уже загружаю

[Boxa]

Обновился, стало намного лучше... Спасибо за наводку =)

[romabrew]

Здравствуйте! подскажите пожалуйста, если диалоговое окно больше размеров экрана, можно ли ему добавить полосы прокрутки сбоку или снизу? см. вложения

Код:

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

dlg:dialog{
label="Построитель";
  :column{
  :edit_box{key="num_strok";edit_width=10; label="Количество столбцов";}
  :edit_box{key="num_stolb";edit_width=10; label="Количество строк";}
  }// column
  
  :button{      
   key="bt_Accept";   //Имя кнопки в LISP-программе
   label="Далее >>";   //Надпись на кнопке
   is_default=true;   //Срабатывает, если нажат Enter;
   }// button "Далее"
   
   :row{fixed_height=true;
      
   :column{label="Горизонтальные размеры:"; 
   :edit_box{key="key1";edit_width=10; label="1";}
   }// column "Горизонтальные размеры"
   
   :column{label="Вертикальные размеры:"; 
   :edit_box{key="key2";edit_width=10; label="1";}
   :edit_box{key="key3";edit_width=10; label="2";}
   :edit_box{key="key4";edit_width=10; label="3";}
   :edit_box{key="key5";edit_width=10; label="4";}
   :edit_box{key="key6";edit_width=10; label="5";}
   :edit_box{key="key7";edit_width=10; label="6";}
   :edit_box{key="key8";edit_width=10; label="7";}
   :edit_box{key="key9";edit_width=10; label="8";}
   :edit_box{key="key10";edit_width=10; label="9";}
   :edit_box{key="key11";edit_width=10; label="10";}
   :edit_box{key="key12";edit_width=10; label="11";}
   :edit_box{key="key13";edit_width=10; label="12";}
   :edit_box{key="key14";edit_width=10; label="13";}
   :edit_box{key="key15";edit_width=10; label="14";}
   :edit_box{key="key16";edit_width=10; label="15";}
   :edit_box{key="key17";edit_width=10; label="16";}
   :edit_box{key="key18";edit_width=10; label="17";}
   :edit_box{key="key19";edit_width=10; label="18";}
   :edit_box{key="key20";edit_width=10; label="19";}
   :edit_box{key="key21";edit_width=10; label="20";}
//   :edit_box{key="key22";edit_width=10; label="21";}
//   :edit_box{key="key23";edit_width=10; label="22";}
//   :edit_box{key="key24";edit_width=10; label="23";}
//   :edit_box{key="key25";edit_width=10; label="24";}
//   :edit_box{key="key26";edit_width=10; label="25";}
//   :edit_box{key="key27";edit_width=10; label="26";}
//   :edit_box{key="key28";edit_width=10; label="27";}
//   :edit_box{key="key29";edit_width=10; label="28";}
//   :edit_box{key="key30";edit_width=10; label="29";}
   }// column "Вертикальные размеры"
   }// row
  }

[Alan]

Сообщение от romabrew если диалоговое окно больше размеров экрана,

Второй PrintScreen отвечает на твой вопрос.
Полосы прокрутки возможны в падающих списках внутри диалогового окна.
Замени edit_box на popup_list

[romabrew]

Сообщение от Alan Замени edit_box на popup_list

не, popup_list не даст же мне ввести значение ручками, а только предложит выбрать из заранее заготовленного списка. Мне падающий список не нужен, нужно длинное диалоговое окно. Edit Box ов может быть один а может сто в различных случаях

[Alan]

Сообщение от romabrew а только предложит выбрать из заранее заготовленного списка.

Этот список можно готовить при работе программы "на лету"
Можно конечно посмотреть DOSLib
Но! Самое правильное решение - переходить на внешние программы, работающие с Автокадом через СОМ-сервер.
Например так

[romabrew]

Да я весь диалог готовлю на лету. В зависимости от количества полей (ячеек), меняется количество Edit Box. Вот и столкнулся с проблемой, что длинные диалоговые окна на помещаются на экран. То ли я чего то не понимаю, то ли вообще в DCL такого не сделать. В принципе мне требуется нечто подобное , что в вашем вложении. Как и с помощью чего это сделано? я пытаюсь повторить это:

[Кулик Алексей aka kpblc]

Не лечится. Делай несколько окон (если так без dcl никак не обойтись) и доп.кнопки по переходу между ними типа "Далее" и "Назад" - это как вариант.

[romabrew]

Сообщение от Кулик Алексей aka kpblc если так без dcl никак не обойтись

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

[Сергей812]

Сообщение от Alan Но! Самое правильное решение - переходить на внешние программы, работающие с Автокадом через СОМ-сервер.

Медленно через com- у меня больше 4-5тыс обращений/сек к аutocad2012 не выжималось)

Сообщение от romabrew да не то что бы не обойтись. вариантов много. просто я начал с DCL, потому что знаком с ним. А тут проблема на ровном месте

Может, написать часть функционала в виде лисп-функции на Net (смотрите, например, от Бушмана Андрея)?

[ShaggyDoc]

Медленно через com- у меня больше 4-5тыс обращений/сек к аutocad2012 не выжималось)

А это уж зависит от того, как именно COM-сервер написан, как к нему обращаться. Да и нужны ли несколько тысяч обращений в секунду для диалогового окна? Но преимущество COM в универсальности - их можно использовать не только в Автокаде, но и в любых других программах, не меняя ни строчки кода.

Может, написать часть функционала в виде лисп-функции на Net (смотрите, например, от Бушмана Андрея)?

Разумеется можно. Это очень хорошо, что еще и на NET появилась возможность программировать. Но в примере "тихое" чтение XML, причем использующее именно методы NET, а они далеко не самые быстрые. Тоже самое можно сделать и другими способами - быстрее, используя другие методы работы с XML.

Но вопрос именно о диалоговых окнах. Вот тут действительно от DCL надо уходить, раз уж Аутодеск их никак не развивает. Нечего время на них терять - "визу много, шерсти мало". Особенно на современном этапе, когда имеется несколько альтернатив, на любой вкус.

[mkung]

Существует ли возможность перевода строки в label? Например, чтобы подпись кнопки была в 2 строки.

[gomer]

Сообщение от mkung Существует ли возможность перевода строки в label? Например, чтобы подпись кнопки была в 2 строки.

да, но не в автокаде

[Кулик Алексей aka kpblc]

Точнее, "не в dcl"

[gomer]

Точнее "в dcl, но не в автокаде"

Код:

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

dlg : dialog 
 { label="DCL диалог";
  : text  { alignment = centered; label= "Спецыально\nдля KPbICa";}
  : button{label="Большая\nКРАСНАЯ\nКнопка\n";}
  ok_cancel;
}

[trushev]

Сообщение от gomer : button{label="Большая\nКРАСНАЯ\nКнопка\n";}

В три строки не работает. Только в одну строку через пробелы.
При запуске из lisp'а в автокаде.

[gomer]

Сообщение от trushev В три строки не работает

Сообщение от gomer да, но не в автокаде

имелось ввиду, что в автокаде нельзя создавать мультистрочные элементы, в других приложениях, например в брикскаде - можно!

[Кулик Алексей aka kpblc]

gomer, уговорил

[mankurt]

Подскажите, пожалуйста, кто-нибудь, используя какие функции можно вставить в диалог DCL окно с отображением выбранного блока? Функционально должно выглядеть, как в команде _bedit - выбор блока из списка -> отображение картинки блока в окне. Не понимаю, как это можно реализовать?

[Кулик Алексей aka kpblc]

Создавай слайд и показывай его - это единственный вменяемый вариант. Потому что делать bmp запаришься. ИМХО, конечно.

[Disney]

Сообщение от romabrew Edit Box ов может быть один а может сто в различных случаях

А заполнить надо будет всё равно один или все сто?

[romabrew]

Да, все сто и получить список размеров. Подразумевается, что в каждом edit box имеется значение по умолчанию и сто раз вводить числа не придется. Вообще я сейчас копаю в сторону дот нет. Там такое сделать можно, только вот не соображу пока как.

[Сергей812]

А почему не хотите, действительно, сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз. В дотнете пользователь тоже "замахается" вводить 100 значений подряд - неужели все значения одинаковы по смыслу или есть какие то группы?

[Alan]

Сообщение от Сергей812 сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз.

Вроде в этой теме да и в других решили, что DCL - это громадный шаг назад

[romabrew]

Сообщение от Сергей812 А почему не хотите, действительно, сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз. В дотнете пользователь тоже "замахается" вводить 100 значений подряд - неужели все значения одинаковы по смыслу или есть какие то группы?

Они сейчас замахиваются вводить значения в командную строку. На самом деле реальный случай это десять двадцать полей. А несколько окон делать несолидно как то получится. Не хочется так делать. Насчет того, что дисиэль это шаг назад, может и так, но для простых окон самое то. Он прост и интуитивно понятен. Ну для меня.

[Сергей812]

Сообщение от romabrew А несколько окон делать несолидно как то получится

если значения связаны в группы-то получиться что-то типа мастера: ввели общие данные, нажали далее - появилось новое окно со следующей группой входных данных и т.д. Ну, или действительно переписывайте в сторону NETAPI - если не жалко будет времени, потраченного на текущий вариант программы.

----- добавлено через ~20 мин. -----

Сообщение от romabrew Там такое сделать можно, только вот не соображу пока как.

Ну смотря на чем писать будете диалоги - если на WinForm, то можно использовать тот же TabControl. Если WPF - то там вообще принцип матрешки: элементы внутри контейнеров.

[Alan]

Сообщение от romabrew Насчет того, что дисиэль это шаг назад, может и так, но для простых окон самое то. Он прост и интуитивно понятен. Ну для меня.

Ну для меня тоже это проще...
Написал их достаточное количество, поэтому небольшой опыт для сравнения с тем вариантом, что я показывал есть.
Одна диагностика введенной информации во внешней программе чего стоит!
Ну раз DCL для этого не случая не преступление, ваяй!
Вариантов размножения текст-боксов много, сам предлагал да и коллеги подсказывали.
Найди причинно-следственную связь ввода инфы, сделай контроль её ввода и тоже будет не плохо.
Я вот попытался выполнить с помощью DCL выполнить то окно ввода значений кол. и значений шагов.
Получилось ИМХО вполне компактно.

[ShaggyDoc]

Замечу, что помимо чисто визуального контроло-кидательства необходима еще и обработка данных, их хранение, контроль безошибочного ввода.

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

[Alan]

Сообщение от ShaggyDoc Ну и другие визуальные компоненты для отображения данных, которые есть во всех системах разработки, но нет в DCL.

Пытался я >romabrew в п.106 и 127 объяснить это, он вроде загорелся.
Но!... получилось как у многих юзеров: "Я так привык!"

[romabrew]

Сообщение от Alan Я вот попытался выполнить с помощью DCL выполнить то окно ввода значений кол. и значений шагов. Получилось ИМХО вполне компактно.

Да, как вариант. Но все таки я уже направился в сторону .NET. Планирую так, из лисп-функции вызывается лисп-функция дотнетовская, которая возвратит значение в нужном виде. Что то типа такого:

Код:

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

 (defun q2 ()
  (command "_netload" "D:\\lispconnect.dll") ; в dll сборке имеется функция fun, которая описывает диалоговое окно и его поведение
  (setq pppv (fun)); в переменную pppv записывается результат выполнения
(princ)
)

с дотнет функцией, если сам не осилю, надеюсь добрые люди помогут.

Сообщение от ShaggyDoc Использование связей таблиц "master-detail" легко позволяет организовать любую иерархию информации.

можно поподробней?

[Кулик Алексей aka kpblc]

Поподробнее - это практически любое руководство по любой СУБД: таблицы, связи типа "один-к одному" / "один-ко многим" / "многие-ко многим", запросы, отчеты и т.п. Добро пожаловать в мир SQL

[Сергей812]

И если уж решили переходить на Net - то подумайте, стоит ли тащить за собой основную программу на lisp. Поддержка взаимодействия между старым lisp кодом и внедряемыми net-функциями может оказаться "дороже", чем переписать код. Благо "дружелюбность" редактора той же Visual Studio Express в несколько раз повышает скорость написания кода.

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc Поподробнее - это практически любое руководство по любой СУБД: таблицы, связи типа "один-к одному" / "один-ко многим" / "многие-ко многим", запросы, отчеты и т.п. Добро пожаловать в мир SQL

Ну, так можно вообще перепугать Одно "Введение в SQL" 1160 страниц.
На самом деле для начала всё гораздо проще, тем более что в современных средах программирования значительная часть кода делается автоматом, а сложнейший функционал просто спрятан в компонентах.

А примером того, как не надо делать является весьма популярная на форуме программа «Прокат» Василия Кондрата. Она делает простые, но учень нужные всем вещи - разрезы прокатных профилей. Потому и популярна. Но организована безобразно. Но замечу, что претензий к автору нет - когда-то, где-нибудь в AutoCAD R10 (т.е. 25 лет назад) делать можно было если не совсем так, то примерно так - не было инструментальных средств. Хотя и тогда можно было использовать БД.

1. Для такой программы нужны данные - размеры профилей, которые бывают разных видов (уголки, двутавры и т.д.). Причем возможно появление новых видов. У Кондрата данные хранятся в текстовых dat-файлах в виде ЛИСП-списков, наподобие

Код:

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

 ("10Б1" "12Б1" "12Б2" "14Б1" "14Б2" "16Б1" "16Б2" "18Б1" "18Б2" "20Б1" "23Б1" "26Б1" "26Б2" "30Б1" "30Б2" "35Б1" "35Б2" "40Б1" "40Б2" "45Б1" "45Б2" "50Б1" "50Б2" "55Б1" "55Б2" "60Б1" "60Б2" "70Б1" "70Б2" "80Б1" "80Б2" "90Б1" "90Б2" "100Б1" "100Б2" "100Б3" "100Б4" "20Ш1" "23Ш1" "26Ш1" "26Ш2" "30Ш1" "30Ш2" "30Ш3" "35Ш1" "35Ш2" "35Ш3" "40Ш1" "40Ш2" "40Ш3" "50Ш1" "50Ш2" "50Ш3" "50Ш4" "60Ш1" "60Ш2" "60Ш3" "60Ш4" "70Ш1" "70Ш2" "70Ш3" "70Ш4" "70Ш5" "20К1" "20К2" "23К1" "23К2" "26К1" "26К2" "26К3" "30К1" "30К2" "30К3" "35К1" "35К2" "35К3" "40К1" "40К2" "40К3" "40К4" "40К5" "24ДБ1" "27ДБ1" "36ДБ1" "35ДБ1" "40ДБ1" "45ДБ1" "45ДБ2" "30ДШ1" "40ДШ1" "50ДШ1")
("0" 100.0 55.0 5.7 94.3 4.1 0.0 7.0 0.0 ("G = 8,1 кг" "h = 100 мм" "b = 55 мм" "s = 4,1 мм" "t = 5,7 мм" "R = 7,0 мм" "r 1 мм max" "A = 10,32 см2" "Jx = 171 см4" "Wx = 34,2 см3" "ix = 4,07 см" "Sx = 19,7 см3" "Jy = 15,9 см4" "Wy = 5,8 см3" "iy = 1,24 см"))
...
("90" 496.2 303.8 21.0 475.2 14.2 0.0 26.0 0.0 ("G = 155,0 кг" "h = 496,2 мм" "b = 303,8 мм" "s = 14,2 мм" "t = 21,0 мм" "R = 26,0 мм" "r 3,0 мм max" "A = 198,00 см2" "Jx = 86010 см4" "Wx = 3470,0 см3" "ix = 20,80 см" "Sx = 1950,0 см3" "Jy = 9830,0 см4" "Wy = 647,0 см3" "iy = 7,05 см"))

Таких файлов имеется 18 штук. Что в них написано, кто знает? Конечно, разобраться можно, но с трудом. А как их редактировать? Можно, конечно, но вероятность ошибок очень велика.

2. Здесь достоинство в том, что такой список с помощью Лисп можно прочитать и сразу "разложить" по переменным. Но при этом надо абсолютно точно знать, что скрывается за каждым номером элемента списка.

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

4. Еще нужны и иллюстрации к профилям. Они сделаны в виде "слайдов" (которые еще надо сделать) и помещены в библиотеку (которую надо собрать). Надо еще программно и безошибочно показать нужный слайд.

Ну и так далее. А как можно было бы сделать:

1. Создать файл базы данных, например формата MDB от MS Access. С помощью самой Access создать несколько таблиц:
а)Виды проката с полями ID, NAME, IMAGE, NOTE и LISP. В поле ID - уникальный номер, NAME - название вида профиля, NOTE - какое-нибудь длинное описание, IMAGE - растровая картинка, а LISP - имя функции рисования.

б) Профили для каждого вида проката с его данными. Теми, которые необходимы и для рисования сечений и для разных расчетов. При этом не дублировать информацию, т.е. не писать в одном поле число 55.0, а в другом поле "b = 55 мм". Немного пошевелив мозгами можно придумать и единую структуру данных для всех видов проката, т.е. значительно упростить работу.

2. Разработать в подходящей любимой (у каждого может быть своя) среде программирования программу (диалоговое окно) и для редактирования данных и для выбора данных. В этой программе должны быть установлены связи между таблицами Виды проката и Профили по ключевым полям. В результате может быть два отопбражаемых списка - Вид проката и Профиль. При выделении Вида проката в одном списке отображаются Профили, относящиеся только к этому виду. Будет показана и картинка, и подробное описание. И все это можно "на лету" редактировать. Можно, для упрощения работы, сделать кнопку Редактор, по которой отображаются все поля и допускается их изменение, или отображаются только основные данные.

Здесь самое главное, что для работы с данными можно использовать компоненты классов TDataSet и TDataSource, а для отображения и редактирования данных - любые визуальные компоненты, связываемые с DataSource - навигаторы, сетки, деревья, отдельные поля. Программа сразу умеет двигаться по данным, безошибочно их редактировать, искать, фильтровать и многое другое. Не надо писать ни строчки кода.

3. Такой "диалог" запускается из LISP-программы известными способами. При выборе нужного профиля диалог закрывается, а в LISP возвращается имя функции рисования и список данных. Lisp, благодаря своим фундаментальным возможностям, выполняет функцию с заданным именем и с переданными данными. Разумеется, такая функция в этот момент должна быть определена, например в библиотеке.

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

Освоение таких технологий даст безграничные возможности. А время на это надо будет потратить меньше, чем на мучения с ублюдочным DCL. Его время закончилось одновременно с появлением еще Windows-95.

[Сергей812]

Сообщение от ShaggyDoc 1. Создать файл базы данных, например формата MDB от MS Access. С помощью самой Access создать несколько таблиц:

На Access часто экономят при покупке офиса. Наглядный пример - одна российская фирма (имени называть не буду во избежание рекламы) выпустила для продвижения своей продукции расчетную программу для расстановки оборудования. И, не долго думая, влепили БД на Аccess. Прошел год - и вышла новая версия программы, которая для своей работы уже не требовала Access - т.е. к ним поступила далеко не единичное замечание от пользователей по этому поводу. Иначе они бы и не "чесались")

[ShaggyDoc]

Сообщение от Сергей812 На Access часто экономят при покупке офиса. Наглядный пример - одна российская фирма (имени называть не буду во избежание рекламы) выпустила для продвижения своей продукции расчетную программу для расстановки оборудования. И, не долго думая, влепили БД на Аccess. Прошел год - и вышла новая версия программы, которая для своей работы уже не требовала Access - т.е. к ним поступила далеко не единичное замечание от пользователей по этому поводу. Иначе они бы и не "чесались")

Для использования в программах базы данных в формате Access, т.е. MDB сама программа MS Access совершенно не обязательна. Я просто упомянул её как инструмент для создания структуры БД, да и то для начинающих. Причем инструмент самый неудобный, но "с кнопками". Зато у неё нет окна для прямого ввода и выполнения SQL, что замедляет работу в десятки раз.

Для работы необходим "движок" Jet, который распространяется Microsoft бесплатно. Но и это только если захочется работать с БД через механизмы ADO. Например, чтобы прямо из LISP выполнить SQL-запрос и получить данные вообще без лишних посредников. Но можно и работать через компоненты прямого доступа к MDB.

Вообще-то есть разные локальные БД, в том числе гораздо быстрее и удобнее MDB. Я, например, использую Absolute Database - она просто встраивается в программу, не имеет никаких "движков", DLL, хранит любые виды данных и полностью совместима с SQL. Но это уже вопросы религии - кто "продал душу дьяволу" (т.е. Microsoft) на такое пойтить не может.

[Сергей812]

Сообщение от ShaggyDoc Я, например, использую Absolute Database

Если имеется в виду эта БД, то там есть

An individual may use Absolute Database Personal in a project if he / she is the only user of this project. If your project is public or if you represent a company, you must order commercial edition of Absolute Database.

[ShaggyDoc]

Если имеется в виду эта БД, то там есть

Ну так и покупаю. Делов-то. Зато имеются все исходники и работа многократно упрощается. Но есть и другие СУБД, бесплатные. Например Firebird, который может быть и сервером, и "embedded", т.е. локальной СУБД. Есть SQLite - для всех платформ.
А для большинства MDB подойдет. Только надо с умом использовать, и применять более удобные инструменты разработчика, которые тоже имеются бесплатные.

[trir]

Зато у неё нет окна для прямого ввода и выполнения SQL

есть

[ShaggyDoc]

Сообщение от trir есть

А ну-ка скриншот. Может быть в какой-то последней версии. Только не надо путать конструктор SQL-запроса, из которого можно потом скопировать выражение (это есть) с обычным окном текстового редактора, в который можно вписать что угодно и выполнить.

Вот такое окно - непременный элемент всех (кроме Access) программ класса "database desktop". Именно с его помощью можно делать любые "чудеса" с базами данных.

А MS Access - программа для "конечных" пользователей, и, по мнению Microsoft, им это не надо. Пусть, мол, кнопки жмут, да "мастерами" пользуются. А еще и создает в MDB кучу ненужных служебных таблиц, раздувающих базу. Потому сторонние программисты и пишут множество заменителей Access.

[trir]

Кажется всегда был "Режим SQL" (в 2003 точно), в нём можно создавать хранимые процедуры и скрипты (создание таблиц с индексами и т. п.)
Хотя сделать можно и не всё...

[gomer]

вы темой не ошиблись?

[ShaggyDoc]

Кажется всегда был "Режим SQL" (в 2003 точно), в нём можно создавать хранимые процедуры и скрипты (создание таблиц с индексами и т. п.) Хотя сделать можно и не всё...

Вот это как раз то, за что MS и не любят. Сначала надо сделать именованный запрос, "сконструировать" его, забить им БД, и только потом увидеть SQL. Да и то специфичный диалект, не очень совместимый со стандартом. Это называется изображением "и у нас, как у людей".

вы темой не ошиблись?

Нет. Это всё гвозди в гроб DCL.

[gomer]

Сообщение от ShaggyDoc Нет. Это всё гвозди в гроб DCL.

базы данных - это средства хранения и обработки информации... DCL - это пользовательский интерфейс для программ на лиспе... это как литры и километры сравнивать... если пользователю нужно ввести 3 числа, то DCL ему вполне подойдет, если ему нужно ввести 100 чисел, то может что-то он не правильно делает...

[trir]

если ему нужно ввести 100 чисел, то может что-то он не правильно

ага, явно нужна БД

[trushev]

Сообщение от romabrew Да я весь диалог готовлю на лету. В зависимости от количества полей (ячеек), меняется количество Edit Box. Вот и столкнулся с проблемой, что длинные диалоговые окна на помещаются на экран. То ли я чего то не понимаю, то ли вообще в DCL такого не сделать.

Осмелюсь предложить свое решение проблемы в DCL окне. Предлагаю заменить сотни полей edit_box на одно list_box, куда и загружать список данных созданных на лету. Поле edit_box использовать для корректировки и ввода данных. Работу окна организовать аналогично приведенному примеру, где
1 - поле popur_list устанавливает режим работы,
2 - служит для вывода сообщений и пояснений по работе с программой в text_part,
3 - поле list_box с текущем списком данных,
4 - поля edit_box в которые вводятся данные для дополнения списка поля list_box или загружаются параметры выбранной строки поля list_box для корректировки.
Обновление поля list_box выполняется либо выбором клавиши "ИЗМЕНИТЬ", либо нажатием Enter.

[ShaggyDoc]

Сообщение от trushev Осмелюсь предложить свое решение проблемы в DCL окне. Предлагаю заменить сотни полей edit_box на одно list_box, куда и загружать список данных созданных на лету. Поле edit_box использовать для корректировки и ввода данных. Работу окна организовать аналогично приведенному примеру, где 1 - поле popur_list устанавливает режим работы, 2 - служит для вывода сообщений и пояснений по работе с программой в text_part, 3 - поле list_box с текущем списком данных, 4 - поля edit_box в которые вводятся данные для дополнения списка поля list_box или загружаются параметры выбранной строки поля list_box для корректировки. Обновление поля list_box выполняется либо выбором клавиши "ИЗМЕНИТЬ", либо нажатием Enter.

Вот это как раз пример архаичности DCL. Всю эту кучу "контролов" может заменить один DbGrid. "Сетка" сама умеет и редактировать данные, и сохранять, и удалять и всё прочее. И весь "список данных" надо хранить в таблице, в том числе между сеансами работы.

базы данных - это средства хранения и обработки информации... DCL - это пользовательский интерфейс для программ на лиспе...

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

А вот с приведенным примером "решения проблемы DCL в окне" как раз надо писать много кода для заполнения и обработки "контролов". В том-то и беда, что Аутодеск наплевала на LISP и DCL.