[TwoZero]

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

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

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

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

[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, учитывая, конечно, что в первом случае - меньше "плюшек").

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

[Дима_]

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