[Shraybicus]

Доброй ночи!

В общем вопрос в название. Что может быть в качестве слайда? Может быть например изображение в формате jpeg или bmp и др.?

[ShaggyDoc]

Сообщение от Дима_ Подскажите каким методом определяете местоположение exe'шника (у меня пока в виде "жесткой" привязки %appdata%... реализовано, ничего лучше в голову не приходит (в реестр лезть или переменые устанавливать - не охота, (тогда уж сразу COM поставить можно) может какой получше метод есть - поделитесь)).

Ну, мало ли чего неохота. Если это свой EXE, то его просто надо инсталлировать цивилизованным методом, а результат инсталляции (место) - записать в реестр, в HKCU\MyApp. И потом оттуда получать место "прописки". Записывать надо именно в реестр, т.к. HKCU\MyApp является константой для этого приложения. И это должен сделать инсталлятор.

Можно бы настройки и в файле хранить, но тогда придется решать вопрос с местом жительства этого файла. Удобен компромиссный вариант: основные пути в реестре, прочие настройки - в файлах, путь к которым извлекается из реестра. Причем эти файлы должны храниться не в %appdata% %ProgramFilesFolder%, а в %AppdataFolder% или %CommonAppdataFolder%.

%ProgramFilesFolder% (как переменную) использовать можно, но до нее тоже еще добраться надо, да и может потребоваться ставить программу в любое место. Чтобы работать с реестром совсем не надо ставить COM.

PS. Как обычно обозначаются системные папки в WinApi:

ProgramFilesFolder - папка в Program Files. Ставим сюда только то, что не должно изменяться пользователем

AppdataFolder - где-то в c:\Documents and Settings\%USER%\Application Data\ (для XP)

CommonAppdataFolder - где-то в c:\Documents and Settings\All Users\Application Data\ (для XP)

[gomer]

Вы все забыли одно маленькое преимущество слайдов: слайды (снимки рабочего поля) делаются одним нажатием клавиши, можно даже динамически, в диалоговом окне
Модальность DCL тоже не проблема, если не пытаться впихнуть в него несвойственный функционал...
Новые контролы? А часто вы их используете? А правильно ли? А можно ли и без них обойтись? А удобны ли они на самом деле? А сколько времени занимает разработка действительно нового контрола... А насколько больше exe-шник файла DCL и т.д.

[ShaggyDoc]

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

Это было преимуществом в DOS, когда получить изображение с экрана было проблематично. Сейчас это называть "преимуществом" смешно. Все остальные рассуждения из серии "слаще редьки ничего не хочу".

Конструирование DCL-диалогов - мучение. Работа вслепую с многочисленными запусками для проверки. Ужасное "саморастягивание" элементов. Ужасный, по современным понятиям код, обработки.

Да, когда-то все диалоги писались примерно так - указывая вручную позиции и размеры (в DCL даже размером только косвенно можно управлять). Но это было когда-то. Всё-таки уже минимум 15 лет используется визуальное конструирование форм, его даже в свои программы вставляют. Дополнить IDE "Visual" LISP такими возможностями мог бы и студент, в рамках максимум дипломной работы.

В очередной раз привожу пример диалога не на DCL. Там есть Control (дерево), без которого кому-то можно и обойтись. В дереве отображаются "пункты меню". Каждый пункт сопровождается иллюстрацией, которую в любой момент обычный пользователь может заменить щелчком одной кнопки (есть несколько вариантов). Иллюстрацию еще и подредактировать "на лету" можно. Каждый пункт имеет дополнительное описание.

Дерево меню читается из XML-файла, который "кому положено" могут и редактировать. И дерево умеет выполнять "команды", которые привязаны к пунктам меню.

Попробуйте реализовать это на LISP+DCL. А показанное на рисунке меню в LISP вызывается одной строчкой:

(ru-xml-eval full_xml_file_name dlg_caption)

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

[hwd]

>ShaggyDoc
Поскольку у вас есть готовые решения, может имел бы смысл опубликовать одно из них в качестве примера? То, что вы предлагаете, несомненно гораздо лучше, чем использование DCL, но LISP-программистам, как мне кажется, было бы легче освоить данный вариант взаимодействия кода с GUI, если бы перед глазами был комментированный пример. Алексей Кулик закрепил бы тему в соответствующем разделе. ИМХО - подобные примеры никогда не будут лишними и если в примере будет подробно разобрано построение, к примеру, показанного вами выше окна + взаимодействие с ним Lisp-кода - я думаю, что очень многие будут вам признательны.
______________
P.S. Это конечно если у вас есть на то время/желание и более менее подходящий исходный код под рукой, на комментирование которого не уйдёт много времени (если комменты не присутствуют на данный момент времени).
P.S.2 Со своей стороны могу предоставить .Net-реализацию примера, который вы опубликуете (возможно это кому-нибудь будет интересно). Реализацию я предоставил бы в двух вариантах - с применением WinForms и с применением WPF, дабы можно было сравнить обе технологии построения GUI в дотнете.

[Дима_]

Сообщение от hwd но LISP-программистам, как мне кажется, было бы легче освоить данный вариант взаимодействия кода с GUI

внимательно прочитайте вышенаписанное - с этой формой нет никакого "взаимодействия" из лиспа (не считая ее вызова) - форма взаимодействует с объектной моделью автокада и написанна она может быть на чем угодно (в том числе и .Net). Знания Autolispa здесь, ну ни как не помогут.
P.S. так-что получится - выкладывать надо одно и то-же (у Вас на .Net, а у ShaggyDoc - например - на дельфи - лисопом "не пахнет" в обоих случаях).
P.P.S - чтобы было взаимодействие из лиспа - выход только один - писать GUI COM сервер.

[hwd]

Сообщение от ShaggyDoc Причем эти файлы должны храниться не в %appdata% %ProgramFilesFolder%, а в %AppdataFolder% или %CommonAppdataFolder%. %ProgramFilesFolder% (как переменную) использовать можно, но до нее тоже еще добраться надо, да и может потребоваться ставить программу в любое место. Чтобы работать с реестром совсем не надо ставить COM. PS. Как обычно обозначаются системные папки в WinApi: ProgramFilesFolder - папка в Program Files. Ставим сюда только то, что не должно изменяться пользователем AppdataFolder - где-то в c:\Documents and Settings\%USER%\Application Data\ (для XP) CommonAppdataFolder - где-то в c:\Documents and Settings\All Users\Application Data\ (для XP)

Windows XP SP3 x86 Rus - системные переменные %ProgramFilesFolder%, %AppdataFolder% и %CommonAppdataFolder% отсутствуют, проверял так - вставлял эти переменные в командную строку проводника, ожидая, что они будут работать по аналогии с %appdata%, %allusersprofile%.
Для того, чтобы получить список системных переменных, можно в cmd.exe запустить команду SET. Как вариант - запустить этот скрипт.

Сообщение от Дима_ с этой формой нет никакого "взаимодействия" из лиспа (не считая ее вызова) - форма взаимодействует с объектной моделью автокада и написанна она может быть на чем угодно (в том числе и .Net). Знания Autolispa здесь, ну ни как не помогут.

Вызов exe из Lisp, с последующим запуском из запущенного exe-шника Lisp-команд при закрытии окна, передавая этим командам нужные параметры (если я верно понял автора) - это я подразумеваю под "взаимодействием". Код диалогового окна возможно будет интересен тем, кто пишет не только на Lisp, но и на Делфи.

Сообщение от ShaggyDoc Сейчас я немодальные диалоги делаю именно в виде EXE. Он запускается из LISP, подхватывает объектную модель AutoCAD и посылает ему соответствующие "команды".

[ShaggyDoc]

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

Все это опубликовано с исходниками в книге "САПР на базе AutoCAD - как это делается" (глава 16). С тех пор произошла только незначительная правка.

Со своей стороны могу предоставить .Net-реализацию примера, который вы опубликуете (возможно это кому-нибудь будет интересно). Реализацию я предоставил бы в двух вариантах - с применением WinForms и с применением WPF, дабы можно было сравнить обе технологии построения GUI в дотнете.

Да, это было бы интересно и полезно. Здесь, вообще-то и не нужен код самой моей программы. Даже будет вреден - свой, возможно, будет более оптимальным. В показанном диалоге главное - синтексис XML. Вернее, не синтаксис (он стандартный), а имена атрибутов и прочее.

Но даже описывать не буду - просто приложу несколько XML в архиве. По ним будет все понятно. А чего непонятно - объясню.

Обращаю только внимание на возможность включения других XML строчкой типа

Код:

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

<item name="Разные линии" include="common\ru_all_lines.ruxm" />

в xml\menu\common\ru_all_draw.ruxm

Парсер XML, встретив такую строку, вставляет вместо нее в DOM дерева содержимое include-файла. А в нем могут быть и другие вложения. Это дает очень большие возможности - можно и "весь САПР" приязать к одной кнопке, и обращаться по отдельности к любому разделу.

Можно потренироваться на xml\menu\other\pltools.ruxm - в него вошли команды из PlTools от VVA, которые имеются на форуме.

Строка, которая должна возвращаться в LISP сидит в атрибуте macro, например

Код:

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

macro="(ru-app-load "common\\ru_draw_by_object")"

Вот этот атрибут надо внимательно заполнять - с учетом разделителе и кавычек в XML и LISP.

B такой диалог, конечно, может использоваться не только для LISP. У меня один и тот же COM-сервер используется и в других системах. Например, в Mapinfo, где также имеются сотни утилит в которых "без картинок" не разберешься. Там вместо возврата значения атрибута macro возвращается значение атрибута filename. А какой именно атрибут возвращать - передается в аргументах запуска.

[Pastor]

А что, если диалоговые окна в AutoCAD'е писать на HTML/CSS/JavaScript. Можно всё делать очень круто и богато. Особенно если заручиться поддержкой таких библиотек, как jQuery.
Всех дел то, написать специализированный браузер

[hwd]

Сообщение от Pastor А что, если диалоговые окна в AutoCAD'е писать на HTML/CSS/JavaScript. Можно всё делать очень круто и богато. Особенно если заручиться поддержкой таких библиотек, как jQuery. Всех дел то, написать специализированный браузер

Если перевести на русский, то имя этому - XAML, а технологии, которые успешно его используют - WPF и Silverlight.

[Pastor]

В переводе на русский это звучит ровно так, как написано: HTML/CSS/JavaScript.
Я имел в виду использовать вместо языка разметки DCL язык разметки HTML
плюс таблицы стилей CSS. Вся внутренняя логика диалогового окна пишется на JavaScript (VBScript), а необходимая часть событий транслируется "наружу" - передается в обработчик событий прикладной программы, написанный на lisp.

[hwd]

Сообщение от Pastor Я имел в виду использовать вместо языка разметки DCL язык разметки HTML

Почему тогда не XHTML? А если XHTML, то и до XAML рукой подать. имхо.

[Pastor]

Можно и XHTML. Современные версии браузеров умеют отображать и то, и другое.
Можно даже XML + CSS или XML + XSLT.
Насчет XAML не знаю. Наверное требуется спец плагин (Silverlight ?)

[ShaggyDoc]

А что, если диалоговые окна в AutoCAD'е писать на HTML/CSS/JavaScript

Писать можно на чем угодно. Вопрос в другом - чем читать.

HTML, Javascript со всеми его прекрасными библиотеками (jQuery и т.п.) предназначены для ВЕБ-приложений, в которых единственный инструмент - браузер. Они, безусловно, нужны. Но работают в сотни раз медленнее, чем standalone приложения. И уж для замены диалоговых окон AutoCAD это делать не имеет никакого смысла. Для их просмотра понадобится браузер (пусть свой, минимальный). А делать логику обработки таких HTML-окон пробовали? Я ежедневно этим занимаюсь (пишу CMS). Сделать это в десятки раз сложнее, чем пресловутый DCL.

А вот XAML, как язык описания диалогов - весьма перспективно. Именно как единый универсальный язык. Сейчас в каждой системе программирования свои форматы, описывающие одно и то же. А мог бы быть единый. Чтобы диалог, сконструированный в одной системе, можно было прочитать и выполнить в любой другой. Конечно, фирмы на это не пойдут. Но вот Autodesk для AutoCAD могла бы использовать XAML и для .NET, и для VisualLIsp. Да они про это вроде как сами лапшу вешали, когда ложились под Microsoft.

[gomer]

Сообщение от ShaggyDoc Конструирование DCL-диалогов - мучение.

не согласен... Простой диалог пишется в течении максмимум 3 минут, если уметь, сложный - чуть дольше...

[Profan]

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

[hwd]

Сообщение от ShaggyDoc А вот XAML, как язык описания диалогов - весьма перспективно. Именно как единый универсальный язык. Сейчас в каждой системе программирования свои форматы, описывающие одно и то же. А мог бы быть единый. Чтобы диалог, сконструированный в одной системе, можно было прочитать и выполнить в любой другой. Конечно, фирмы на это не пойдут. Но вот Autodesk для AutoCAD могла бы использовать XAML и для .NET, и для VisualLIsp. Да они про это вроде как сами лапшу вешали, когда ложились под Microsoft.

Манагеров учат, что деньги превыше всего (иначе ты не манагер). Отсюда и все нелогичности/недоговорённости между компаниями. имхо.
Поскольку под автокад можно писать на дотнете, то один вариант xaml-парсера уже есть. Другие варианты нужно либо самому писать, либо ждать, когда они будут предоставлены сторонними девелоперскими компаниями.
Теоретически, если напрячься, то под свои задачи можно написать такой парсер (к примеру для использования WinForms).
Кстати, меня очень растроил тот факт, что Mono в своей библиотеке отказалось реализовывать WPF. Пояснения по поводу принятия такого решения, я не нашел...

Offtop: Понимаю, что это будет как камень в болото, но... Кину уж его, выскажусь...
Честно говоря, все проводимые автодеском форумы, дни открытых дверей и т.п. "крутые встречи" - это, на мой взгляд, своего рода слёт одарённых, но тем не менее "Свидетелей Иеговы", пешек (грубо конечно, но ведь по сути так и есть) Autodeska, задача которых громко и уверенно петь "Аллилуйя", компилируя эту же программу у без того откомпилированных присутствующих на мероприятии (таких же "Свидетелей Иеговы"), внушая тем самым идею покупать очередную версию продукта. Разъезжаясь обратно по своим фирмам, они несут "благую весть", "хорошие новости". Но блин, на таких мероприятиях официально не обсуждаются "косяки" и их исправление для текущей и предыдыщих версий продукта. И времени, отведённого под это дело, в программках найти никому не удастся, сколько бы ни искали. Ибо нефиг... Не надо этого... И всё пучком, ибо "масса хавает"...
Тема устранения замечаний "неприятна" и её обсуждение не входит в планы помпезных песнопений, ведь по бизнес-плану пора втюхивать очередную версию продукта (в которую, порой, добавлено что-то, что уже давно присутствет в вертикальных решениях, но преподносится как "новинка"). Оно и понятно - если начать обсуждение "багов" и пожеланий - может получиться не так красиво, как планируется. Лучше всем вместе сделать вид, что всё прекрасно и безоблачно. Плохо, когда компания ставит превыше всего деньги, а не качество. Не буду спрашивать, нахрена каждый год выпускать новую версию, вместо того, чтобы детально "причесать" уже имеющуюся... Ответ итак очевиден.
Помню, как у нас в отделе открыли одно из видео, об осеннем форуме... На нём какой-то парень, со счастливым лицом рассказывал, как он вставая с кровати, первым делом влючает компьютер и запускает Revit, потом идёт чистить зубы, чуть ли не над клавиатурой, после чего весь день он за Revit'ом, и последнее, что он делает непосредственно перед сном - закрывает Revit и выключает компьютер... И мол он так счастлив, так счастлив - в этом вся его жизнь... Вокруг стоят, радостно улыбаются и одобрительно кивают такие же "зомби"... Ужоссс... Такой неприкрытый щенячий восторг...

[gomer]

Сообщение от Profan А про лисп, в котором надо расписать обработку разных полей, забыл? Три минуты, ишь ты.

Разделяйте мух и пчол я говорю о DCL и не съезжаю с темы... хотя... а кокая собственно тема?.. В общем слайдом может быть слайд, слайд в библиотеке... либо lisp выражение...

[Pastor]

Но вот Autodesk для AutoCAD могла бы использовать XAML и для .NET, и для VisualLIsp.

Так для .NET оно и сейчас пожалуйста: используйте библиотеки WPF.
Речь то идет о замене связки DCL + lisp на что то другое (желательно, такое же простое).
Если использовать XAML, то между XAML и lisp должен затесаться некий модуль, который является приложением к AutoCAD, умеет читать XAML, создавать на основе полученной разметки окна, транслировать события(основные), происходящие в компонентах окна, в среду lisp и предоставлять интерфейс для каждого используемого в окне типа компонента (аналогично action_tile, get_tile, set_tile). В этом случае не потребуется ничего, кроме lisp и XAML, но написать такой модуль - серьёзное дело (имхо).

[gomer]

Чем вам OpenDCL не нравится?

[hwd]

Сообщение от Pastor Если использовать XAML, то между XAML и lisp должен затесаться некий модуль, который является приложением к AutoCAD, умеет читать XAML, создавать на основе полученной разметки окна, транслировать события(основные), происходящие в компонентах окна, в среду lisp и предоставлять интерфейс для каждого используемого в окне типа компонента (аналогично action_tile, get_tile, set_tile).

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