[Holon]

Возможно-ли UserForm созданные в VBA использовать вместо DCL для LISP кода.

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

Просмотри тему http://www.autocad.ru/cgi-bin/f1/board.cgi?t=37618iw

[Holon]

Да вот ссылка очень хорошая, конкретный пример

Код:

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

http://www.afralisp.net/vl/vl-vba1.htm

все работает, осталось поковырять vbaide и от DCL-ок можно отказывается

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

И огребешь проблемы при передаче данных в окно VBA и обратно. Через USERS* передать можно далеко не все (кроме, пожалуй, достаточно элементарных вещей). Например, придумай, каким образом передать в лисп, какие флажки отмечены в таком, к примеру, окне (см.аттач) - я с трудом представляю, например, даже примерный алгоритм.
Также попробуй, ради интересу, мышой поменять размер окна. Или динамически добавить / выгрузить в окне, нарисованном в VBA, контролы. Сделай в окне массив объектов. Попробуй, для примеру, использовать в окне сторонний ocx (например, TrueDBGrid) и предоставь свой dvb-проект "на сторону".
[ATTACH]1191346647.jpg[/ATTACH]

[Holon]

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

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

Какие закладки? Tab'ы, что ли?
Понимаешь, я сейчас тоже в раздрае, если честно. С одной стороны, VB6 мне более-менее знаком, с другой - .NET надо использовать, пора уже...
dll-ки, нарисованные в VB6, порождают несколько проблем:
1. Окна, сделанные в VB6, в Windows XP Pro 32bit при "неклассической теме" отображаются некорректно.
2. dll требует обязательной регистрации, что может быть выполнено под правами либо локального, либо доменного администратора. Казалось бы, фигня, но не после 16-го наращивания функционала.
3. В Windows Vista 64bit зарегистрировать такую dll невозможно, как мне сказал Александр Ривилис.
4. Даже если ограничиться Windows XP и Windows Vista 32bit, все равно вместе с самой dll надо предоставлять еще несколько dll и ocx и обязательно выполнять их регистрацию, если версия не более новая. А если более новая, то гарантировать корректность работы твоей dll и Билли вряд ли возьмется.
dll, нарисованные на .NET (и загружаемые в AutoCAD от 2005 и выше командой _netload), лишены этих недостатков. У них свои

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc dll-ки, нарисованные в VB6, порождают несколько проблем: 1. Окна, сделанные в VB6, в Windows XP Pro 32bit при "неклассической теме" отображаются некорректно. 2. dll требует обязательной регистрации, что может быть выполнено под правами либо локального, либо доменного администратора. Казалось бы, фигня, но не после 16-го наращивания функционала. 3. В Windows Vista 64bit зарегистрировать такую dll невозможно, как мне сказал Александр Ривилис. 4. Даже если ограничиться Windows XP и Windows Vista 32bit, все равно вместе с самой dll надо предоставлять еще несколько dll и ocx и обязательно выполнять их регистрацию, если версия не более новая. А если более новая, то гарантировать корректность работы твоей dll и Билли вряд ли возьмется. dll, нарисованные на .NET (и загружаемые в AutoCAD от 2005 и выше командой _netload), лишены этих недостатков. У них свои

Вот ты и понял, почему VB - "ненастоящая" среда для серьезных разработок. :wink:
Хоть он и "вижуал", но все равно - Beginner All Surprose Implementation Code - "универсальный символьный код для начинающих". Так небезызвестный автор придумал. А уж потом, в маркетинговых целях, стали "расшифровывать как "базовый". Без базы, мол, никуда.

Что касается "красивых диалогов" для LISP, то давно убедился:

1. Чаще всего они вообще не нужны. Многое можно и нужно делать опциями командной строки, только с умом. Представьте, например, команду PLINE в диалоговом варианте со множеством управляющих элементов - работать было бы невозможно.

2. Когда диалоги действительно необходимы, можно использовать COM. В том числе и на VB ("большом", но с перспективой тупика).

3. Обмен данными между LISP и диалогом возможен в нескольких вариантах:

а) Через USERxx если диалог на VBA. Это наихудший вариант во всех отношениях.
б) Через файл. Возможен, и оптимален если передавать надо очень много данных. Но надо с умом - файлы должны быть доступны для чтения, записи обычным пользователем, а не только автором программы.
в) Через свойства COM- объектов или в виде аргументов для методов. Это теоретически наилучший вариант, но для сложных данных (например, списков) реализовать сложно. Тут уметь надо, особенно с учетом разных механизмов передачи, например, строк.
г) Через реестр - временные ключи в собственной ветке HKCU. Это работает быстро, программировать легко.

Сами диалоги не обязательно делать большими и навороченными. Уже давно использую всего несколько простых:
1. Иллюстрированное древовидное меню
2. Выбор из линейного списка
3. Выбор из списка с "галочками"
4. Выбор из двухпанельного списка с сортировкой.
5. Окно сообщений на все случаи жизни
6. Окно ввода двух чисел или строк с опциональным выбором из справочников.

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

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

> ShaggyDoc : У меня осознание этого уже с полгода как в голове болтается (правда, без видимых изменений). СОМ-модель - ей же по барабану, как я понимаю, на каком языке нарисована dll - Delphi / VB / VC / FreeBasic etc. Все едино оно прописывается в реестр и в HKRC, и потом уже выполняется его поиск. В Vista64bit, как я понял, технология принципиально иная, то есть этот вариант работать не будет.
Теперь по пунктам разрешите пройтись
а) не оспаривается
б) не очень. Достаточно вспомнить историю поведения Windows XP в домене и попытке записи в %AllUsers%\Aplication Data\<soft>. И потом, файловые операции в Windows самые медленные...
в) По-моему, это определяется методом созданного класса. Если он принимает массив строк, то сделать из списка вариант... По-моему, не проблема. Хотя, может, я и ошибаюсь и в полной мере это дело я не огреб еще.
г) Практически аналог б), только вся разница в скорости и том, что (возможно) не понадобится преобразование данных. Удобство сомнительное, если честно.

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc > ShaggyDoc : У меня осознание этого уже с полгода как в голове болтается (правда, без видимых изменений). СОМ-модель - ей же по барабану, как я понимаю, на каком языке нарисована dll - Delphi / VB / VC / FreeBasic etc.

Теоретически да, по барабану. А практически многое упирается в реализацию - методы-то выполняются в dll. Чтобы "сам VB" работал, ему нужны dll, в которых сам Basic реализован. А что из визуальных элементов (ради них и диалог) реализовано в VB? Два десятка стандартных примитивных элементов. А где "хорошие" брать? Надо искать ActiveX. А их хороших и бесплатных много ли? Да и хорошие ActiveX Control - самая медленная технология.

В VC примерно то же с ассортиментом, но работа гораздо эффективнее. Потому что используются классы. В Delphi ассортимент богаче всех - именно это и привлекает.

Да, делать COM можно хоть в чем - но эффект разный.

б) не очень. Достаточно вспомнить историю поведения Windows XP в домене и попытке записи в %AllUsers%\Aplication Data\<soft>. И потом, файловые операции в Windows самые медленные...

Ну и что же, что история? Каталог-то специально для этого предназначен. Или %User%\Aplication Data\<soft>. Для временных файлов - вообще %Temp%. Хотя файловые операции, конечно, самые медленные, но я писал про "очень много данных". А эти данные потом обычно обрабатываются в Автокад с гораздо меньшей скоростью. Даже большой файл в память Lisp своими стандартными функциями прочитает очень быстро. Мгновенно. Кстати, гораздо быстрее, чем WSH с использованием COM.

в) По-моему, это определяется методом созданного класса. Если он принимает массив строк, то сделать из списка вариант... По-моему, не проблема. Хотя, может, я и ошибаюсь и в полной мере это дело я не огреб еще.

Вот как раз заставить принимать массив строк - проблема. В LISP мы можем работать только с "ActiveX Automation" и тут приходится добавлять из LISP-списка поэлементно.

А вот в Delphi-приложениях можно использовать специальный интерфейс IStrings, который очень удобен. В общем, "уметь надо", как я и писал.

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

г) Практически аналог б), только вся разница в скорости и том, что (возможно) не понадобится преобразование данных. Удобство сомнительное, если честно.

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

Во всех вариантах скорость обработки не видна пользователю. Какая ему разница - выполняется действие за 0.01 сек или за 0.001.

Да ведь выбирать-то приходится из плохого или очень плохого. Самого правильного - сделать настоящий "вижуальный" лисп, с конструированием, хотя бы как в VB, AutoDesk не желает. Да и кишка у них тонка. Хотя программисты давно научились делать в своих программах конструирование форм и диалогов.

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

Насчет массива строк.
Допустим, есть класс со свойством (прошу прощения, но буду использовать VB-шный синтаксис):

Код:

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

Class MyMainClass
Property GetStringsArray(arString() As String)

Скомпилировано в my.dll
Подробности его реализации сейчас не важны.
Из лиспа:

Код:

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

(defun test (str-lst / svr)
  (setq svr (vlax-get-or-create-object "my.mymainclass"))
  (vlax-put-property
    svr
    'getstringsarray
      (vlax-safearray-fill
        (vlax-make-safearray
          vlax-vbstring
          (cons 0 (1- (length str-lst)))
          ) ;_ end of vlax-make-safearray
        str-lst
        ) ;_ end of vlax-safearray-fill
    ) ;_ end of vlax-put-property
  ) ;_ end of defun

Вроде не сильно наврал

[ShaggyDoc]

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

А если к каждой строке надо привязать еще и другие данные?

Все это решаемо, причем разными путями. Можно иметь свойство, а можно иметь метод с аргументами.

Вот в Автокад-10, когда еще никакого DCL не было, а диалоги были нужны, то делал диалог в EXE-файле. Передача параметров - через файл. И все работало, причем очень быстро даже на 286 машинах. Но тогда запуск программы из Автокада был модальным по умолчанию. Памяти было всего 640 кб, сам Автокад "сжимался" примерно до 25 кб, остальное выделялось программе. Дико, по нынешним временам, но работало прекрасно.

Точно так же можно делать и сейчас - это еще один путь.

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

По-моему, в VB 6 по умолчанию значения передаются по ссылке, а вот в .NET - уже по значению. Регламентируется всего одним словом: ByRef или ByVal. СОМ получил массив любых значений и дальше живет с ними: скопировал массив в закрытую переменную и "дальнейшая судьба никого не касается" (ну или почти так). Принципиальной разницы лично я не ощущаю - передавать строки, числа или массив структур (пользовательских типов). Охотно соглашаюсь, что я "не прошел весь путь".

А если к каждой строке надо привязать еще и другие данные?

Это имеется в виду структрура?

Все это решаемо, причем разными путями. Можно иметь свойство, а можно иметь метод с аргументами.

Мне как-то больше понравилось работать со свойствами (скорее всего, это обусловлено тем, что конструктор класса в VB6 переопределить нельзя, а с необязательными аргументами я не игрался); а последовательность аргументов надо четко соблюдать.

Точно так же можно делать и сейчас - это еще один путь.

Ужать AutoCAD до 25 kb? Шутка, конечно. Сейчас тоже придется слегка поизвращаться, чтобы exe-шник запустить в модальном для AutoCAD'a режиме. Хотя Эдуард показывал лисп как раз для таких задач (нa autocad.ru).

[ShaggyDoc]

Диалог в EXE, при всей примитивности решения, имеет и преимущества. Такую программу можно написать на чем угодно. Можно не ломать голову с COM. Нет зависимости от перспектив COM.

Обмен "заданиями" и результатами можно делать через опуии командной строки, файл или реестр.

Конечно, AutoCAD сейчас не сворачивается в памяти. Для запуска в модальном режиме нужна функция. Ее можно сделать в ARX или в COM. Но это может быть единственный ARX или COM - можно воспользоваться и посторонним. А можно и LISP написать - проверка в цикле наличия результата.

EXE может быть и предпочтительней обычной DLL. Вот внедрял в Mapinfo иллюстрированное меню (там тоже может быть много сторонних утилит). Внутри Mapinfo среда программирования MapBasic. Он умеет вызывать функции из обычных DLL, но чтобы обменяться строками, надо делать хитрые манипуляции, например резервировать длину строковой переменной. С EXE все решается просто. А для пользователя внешний результат точно такой же.

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

Ух ты, ни себе чего - обязательное использование строк фиксированной длины... Такое в VB6 только при специальном указании шло, и то строки автоматом, по-моему, дополнялись пустыми символами (могу и путать, прошу не бить ногами в прыжках). Может, тоже перейти на exe-шники?

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc Ух ты, ни себе чего - обязательное использование строк фиксированной длины...

А ведь это тоже Basic. Хоть и Map. Но весьма ублюдочный. Покупаем за приличные деньги, но он даже синтаксис выделять не умеет. Зато умеет работать с географическими объектами. Вообще Mapinfo - удивительная смесь дубовоых и прекрасных решений.

Может, тоже перейти на exe-шники?

Может где-то и надо. В Brics, например. "Лёлик, это же неэстетично! - Зато дешево, надежно и практично!" (С) Во всяком случае есть множество программистов, которые легко сделают EXE, но не умеют делать COM-серверы.

В ruCAD диалоги ввода двух строк и чисел долгое время были в виде EXE. В порядке эксперимента. Или не помню из-за чего.

[BigBrother]

А тем временем Autodesk в wish list внес:

Reanimate DCL Development
Rework DCL

Reanimate LISP Development
Rework of LISP

Но что то мне с трудом верится в реализацию в итоге.

[Holon]

Есть маленький вопрос о среде разработки, все таки решил разобраться с VBA, чтобы в полнй мере понять все недостатки и достоинства данного языка. В командной строке родного ACad-а набираю vbaide и оказываюсь в Microsoft Visual Basic 6.3 для более эфективного знакомства с итерфейсом вышеуказанного продукта решил, почитать статью о первых и вторых шагах разработки програм на VB например здесь
http://bit.pirit.info/forum/viewtopic.php?t=2831 и столкнулся не с соответствием описания среды разработки, в статье говорилось о создании *.exe -шных файлов,
а я у себя даже new project найти немогу, буду благодарен если кто-то внесет ясность.

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

Потому что VBA и VB суть разные вещи. Запуск vbaide, правый пинок на ThisDrawing, Add -> Module или Form или Class. И вперед.

[Holon]

Значит если я правильно понял в Microsoft Visual Basic 6.3 я могу делать программы или вернее приложения на VBA
и создание отдельных программ на VB невозможно из-за ограничения среды разработки.

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

Сообщение от Holon Значит если я правильно понял в Microsoft Visual Basic 6.3 я могу делать программы или вернее приложения на VBA и создание отдельных программ на VB невозможно из-за ограничения среды разработки.

По-моему, ты что-то перепутал. VB позволяет разрабатывать как отдельные приложения, так и dll. Результат его работы обязательно должен быть скомпилирован и может работать (практически) в любой Windows. Макросы VBA не компилируются и могут выполняться только в той среде, в которой они были разработаны. Так, например, макрос Excel'a не будет работать в AutoCAD'e (имею в виду прямую подгрузку) и наоборот.
На MS VB 6.3 ты сможешь сделать ехе или dll, но это сторонняя среда разработки. И к VBA она не имеет никакого отношения (кроме похожего синтаксиса).