[Supermax]

Я думаю, что настало время завести специальную тему по поводу использования объектов СОМ технологии.
Ссылки, описания библиотек DLL, методы, свойства и прочее. Естественно в ключе использования AutoCAD-a на язывак AutoLISP и VBA.


Первая проблема:
Объект WScript.Shell
(setq svr (vlax-get-or-create-object "WScript.Shell"))
; создаем объект
(vlax-dump-object svr T)
; читаем его свойства и методы

Код:

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

; IWshShell3: Shell Object Interface
; Property values:
;   CurrentDirectory = ...Indexed contents not shown...
; Methods supported:
;   Exec (2)
T

Это у меня

А это у людей
http://www.caduser.ru/cgi-bin/f1/board.cgi?t=39974nf

Код:

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

(defun C:TEST()
  (vl-load-com)
  (if (and
        (setq FILE (getfiled "Выберите файл для чтения" "" "csv" 16))
        (setq WS (vlax-get-or-create-object "wscript.shell"))
        )
  (vlax-invoke-method WS
    "run"
    (strcat "notepad.exe\ " FILE)
    4
    :vlax-true)
    )
  )

И это в описании
http://www.script-coding.info/WSH/WshShell.html

Библиотеки исполняемые модули вроде
wscript.exe 5.06.0000.8820
scrobj.dll 5.06.0000.8820
scrrun.dll 5.06.0000.8820
vbscript.dll 5.06.0000.8820

Но не уверен.
Кто и что скажет?

Люди! Сделайте
(vl-load-com)
(setq svr (vlax-get-or-create-object "WScript.Shell"))
(vlax-dump-object svr T)
;;; а потом
(vl-catch-all-apply '(lambda () (vlax-release-object svr)))


на своих машинах!!! Пожалуйста!!!
И скажите что видите.

[Supermax]

Стал изучать jбъекты:

Microsoft Scripting Runtime
C:\WINDOWS\system32\scrrun.dll
Scripting.FileSystemObject
Scripting.Dictionary
Scripting.Encoder


Shell Extension For Windows Script Host
C:\WINDOWS\system32\wshext.dll
Scripting.Signer

И решил прояснить, для себя, в первую очередь, картину с наличием или отсутствием возможности обращения к COM объекту из AutoCAD-а.
Я напишу свое видение вопроса, а если в чем и заблуждаюсь, так очень буду благодарен за поправку.

И так:
СОМ объекты создаются в памяти машины только исполняемыми модулями *.exe или *.com. Некоторые *.exe являются постоянно действующими приложениями, их хорошо видно в диспетчере задач в закладке "Процессы". Некоторые являются только временными программами и они видны и в "Процессы" и в "Приложения". Собственно все *.exe это приложения к основной программе "Операционная система", только некоторые запускает сама ОС при начале работы и выключить их можно только вручную или при сбое, а некоторые запускает сам пользователь, например AutoCAD.

Чтобы в памяти создался COM объект программа должна иметь данные о нем. Некоторые программы содержат такие данные у себя в теле программы, а некоторые содержат их в специальных файлах-библиотках типа *.dll. Некоторые программы сами знают где должен лежать файл с их библиотекой, а некоторым надо прописать путь в реестре к этой библиотеке. Более того, чтобы создать некоторые объекты не достаточно просто прописать путь в реестре, надо еще туда поместить описание самого СОМ объекта. Если мы хотим чтобы при запуске машины сразу создавались нужные СОМ объекты, надо чтобы в реестре они были описаны должным образом.
В библиотеке может содержаться описание десятков объектов, но если в памяти создать все описанные в библиотеках объекты, то никакой памяти не хватит. Поэтому и получается, что из AutoCAD-a мы можем "дотянуться" до объектов
Scripting.FileSystemObject
Scripting.Dictionary
Scripting.Encoder
а до других объектов библиотеки scrrun.dll - нет, поскольку они не описаны в реестре.
Чтобы их описать нужен файл *.reg который собственно и предназначен для добавления в реестр нужных описаний. При установке некоторых программ типа Visual Studio эти описания в реестр прописываются автоматом, а некоторые объекты создаются прямо при прямом взаимодействии этой программы с dll-файлом.

Объектов очень много - море. Здесь и красивые меню, форматки сообщений, обработчики событий и много другое, что может пригодится для работы в AutoCAD-e. Но как быть, если dll-ок тысячи и в каждой десятки объектов?
Не всякую dll-ку можно загрузить из под regsvr32.exe и не всякая заработает без *.reg с описанием нужных объектов. Если для создания объекта нужна прога - то надо ее иметь. Многие dll-ки такими exe-шниками укомплектованы. Word, Exel и прочие тоже создают СОМ объеты пока сами работают. При выключении такие объекты удаляются из памяти.

Есть программы, которые удаляют из памяти не нужные СОМ объекты. Буквально вчера видел, но сюда ссылку дать забыл, а теперь надо по новой искать.

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

Ищу, блин, короче.

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

СОМ объекты создаются в памяти машины только исполняемыми модулями *.exe или *.com.

Необязательно. СОМ-объект может создаваться другим СОМ-объектом.

Чтобы в памяти создался COM объект программа должна иметь данные о нем.

Программа ничего о нем может не знать, в отличие от операционной системы.
Значит так. Насчет Scripting Object и ему подобных - см. ПМ.
На предмет окна открытия файла - я говорил, что тут надо или писать собственный СОМ, или на .NET / arx делать подгружаемое приложение, или рисовать стороннее ехе-приложение.

[Supermax]

Программа ничего о нем может не знать, в отличие от операционной системы.

Это как сказать. Если те exe-шники, что идут в комплекте с самой операционной системой, к примеру тот же regsvr32 считать неотъемлемой частью самой операционной системы - то да, согласен, а если не считать, то чистая оперативка сама ничего не создаст.
С другой стороны, без них она и сама не загрузится.

Естественно, если в программе нет собственного модуля создания СОМ, а используется дополнительный ехе-шник, то программа не содержит не только сведений о структуре СОМ (в dll-ке лежит), но и сама его не создает. Опять же считать прилагаемые ехе-шники неотъемлемой частью программы или нет?

Короче пошла философия.

[Supermax]

Пытаюсь создать прогу на лиспе, в которой в качестве подпрограммы была бы выполнена программа на WBScript. Алгоритм следующий:
Создаем временный объект Техт, и создаем реактор на его изменение. Запускаем через DwgRu-WScript-Exec или DwgRu-WScript-Run скрипт-файл, который заканчивается обращением к AutoCAD.Application.17 или 16, а то и просто без цифр (пока не решил, скорее всего будет автоматическая настройка по результатам опроса версии када), находим там нужный объект типа техт и записываем в него значения переменной из скрипта. По идее, если мы это сделаем, то должен сработать реактор и далее идет считывание из этого техт-а вернувшегося значения из скрипта, и продолжение програмы на лиспе.

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

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

Зачем??? Извини, но у тебя абсолютно неправильный метод работы (практически ИМХО). Технология такова (по крайней мере я применяю):
1. Создается через (vlax-get-or-create-object) СОМ-объект
2. Через vlax-put-property задаются начальные значения свойств.
3. Через vlax-invoke-method или vlax-invoke запускатся нужный метод (который чего-то-там делает), возвращающий какое-то значение (к примеру). На время выполнения метода лисп останавливается.
4. Анализируется полученное значение и продолжается выполнение лиспа.

[Supermax]

Вчера прочел замечательную статью
http://www.nowa.cc/showthread.php?t=65684

Вспомнил молодось, когда прошивал ПЗУ и возился с Ассемблером, правда с тех пор забыл все напрочь. Очень внимательно прочел и понял, что докопаться до функций из DLL можно и без ее регистрации, наличия программ для работы с ней и прочего. И прямо из под лиспа через запуск все того же debug.ехе Да и по памяти шариться и в регистры устройств заглядывать тоже. Если не сойду с ума, обязательно попробую.

[Supermax]

#65
Все это мы проходили и обгрызли как яблоко до голого качана (или кочана?). НО! AutoLISP работает только в AutoCAD-e это раз. Те свойства и методы, которые мы получаем при запуске внешнего приложения из под лиспа не дают полного доступа к работе самой программы и как сделать реактор на события в ней, я лично даже не представляю. Очень многие проги имеют свои собственные языки или слегка, но весьма существенно отличающиеся варианты существующих как например сам автокад. Далеко не все программы создают СОМ объекты для работы с ними из других программ.

Как организовать последовательный диалог двух программ? С передачей интерфейса управления пользователю. К примеру:
Рисуем теплотрассу и одновременно отчерчиваем ее в Старте. Тут нарисовал - туда першло все само и там тебя о чем-то спросило. Ты ответил - опять в кад вывалился и тут продолжил работу. Это конечно так, фантазии. Меня сейчас сам принцип интересует. Туда-сюда. Хочу написать программу сразу для двух приложений.

[Supermax]

Поскольку тут тема про СОМ, то будет полезно дать пару ссылок на статьи про это:
http://www.wasm.ru/publist.php?list=15
Почти все на русском.

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

> #67 : Тогда рисуй реактор на добавление объекта в файл AutoCAD'a, и обрабатывай эти события. Только СОМ-объект создавай не внутри реактора, а вне - иначе система гавкнется.
> #68 : дополнительно http://firststeps.ru/ и там, например, в Visual Basic - как раз все рассмотрено про COM на VB

[Supermax]

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

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

Если бы я знал, что такое Старт и его объектную модель, можно было бы поковыряться. Но! Я искренне убежден, что "если данные можно передать/обработать/получить в/из памяти, то там это и надо делать". Вот скажи, какая разница (теоретически) - создавать объект текста или возвращать результат выполнения метода СОМ-объекта в памяти? Все равно пока метод не завершит свою работу, у тебя AutoCAD afaik будет блокирован (я не рассматриваю .NET-dll, создающие немодальные окна; а также arx-приложения, рассчитанные на те же немодальные штучки).

[Supermax]

Вот тут ты батенька даже задержал меня на пути к кулеру за кипяточком.
Я был бы бы не против, если бы прога "со стороны" записывала данные в область памяти мне известную и доступную, но акромя реестра, я таковой не знаю. Метод не всегда дожидается, пока я что-то там сделаю например с окном ввода текста. Он мне немедленно возвращает вла-объект этого окна, а как от туда выковырять текст, что я ввел - не знаю.

Объект WScript вообще можно использовать только из скрипт-файла,
http://www.script-coding.info/WSH/WScript.html
а там есть такие замечательные методы как ConnectObject который устанавливает соединение с объектом автоматизации для обработки его событий.
Вот это реакторы, так реакторы. Соединяя несколько языков в одну кучу, мы получаем очень не слабый инструмент для создания программ для автокада.

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

А вот сейчас я огребу по полной программе. Во вложении - СОМ-dll, исходники для нее на VB6 и лисп для тестирования под AutoCAD. Перед запуском лиспа dll надо зарегистрировать через regsvr32 (примерно так, как это написано здесь).
Нарисовал второпях, так что за красивость кода не ручаюсь

[Supermax]

Ну "торопяхи" у тебя тоже ничего. Добавить свойства на заголовок и другие надписи и будет круто.
И от кого ты "отгребешь"? За что грести? Как я понял, публику ничему не научишь. Один на миллион если найдется, так и то в антарктиде.

[Supermax]

Никак не получается создать безопасный массив в WBScript. Надо передать координаты вставки текста.

Код:

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

Set Network = CreateObject("AutoCAD.Drawing.17")
Set ModelSpace1 = Network.ModelSpace
dim InsPoint, itog
InsPoint = Array(0,0,0)
itog = ModelSpace1.AddText("Получилось",InsPoint,2)
vbNewLine 
Loop

Этот Arrey по моему не тот массив создает?

[Supermax]

..... все примитивные типы VBScript представлены как Variant, и, соответственно, все массивы представляются в нем как SAFEARRAY элементов типа Variant. В результате VBScript может принимать массивы с элементами других типов, но не позволяет "добраться" до этих элементов. ....

от сюда:
http://www.suncloud.ru/workshop/wdhp...js/vbsvsjs.htm

[Supermax]

Мне надо, чтобы был передан VARIANT, а передается по всей видимости SAFEARRAY .

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

Проанализируй мой код лисповой - я же там как раз передаю variant, сделанный из safearray'a

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

Сообщение от Supermax Никак не получается создать безопасный массив в WBScript. Надо передать координаты вставки текста. Код: [Выделить все] Set Network = CreateObject("AutoCAD.Drawing.17") Set ModelSpace1 = Network.ModelSpace dim InsPoint, itog InsPoint = Array(0,0,0) itog = ModelSpace1.AddText("Получилось",InsPoint,2) vbNewLine Loop Этот Arrey по моему не тот массив создает?

Я не знаю VBScript, но в VB это звучало бы примерно так (пишу без студии и без проверок):

Код:

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

Dim objApp As Object, objDoc as Object
Set objApp = GetObject(," AutoCAD.Application")
Set objDoc = objApp.ActiveDocument
Dim InsPoint(2) As Double, objText As Object
InsPoint(0) = 0#: InsPoint(1) = 0#: InsPoint(2) = 0#
objText = objDoc.ModelSpace.AddText("Типа что-то получилось", InsPoint, 2#)

Аналоги можно посмотреть на caduser.ru в разделе VBA.

[Supermax]

Попробую, спасибо. Только вот я заболел и выйду в эфир не раньше понедельника.