[Apelsinov]

Увидев вот такой код:

Код:

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

(setq
     ShlObj (vla-getInterfaceObject
	      (APEL-ACAD_APPLICATION)
	      "Shell.Application"
	    )
   )
   (setq
     Folder (vlax-invoke-method ShlObj 'BrowseForFolder 0 "" 0)
)

Имею спросить:
что за аргумент ProgID у функции vla-getInterfaceObject (тут "Shell.Application" ) какие значения он может принимать? как получить список возможных значений?

что за объект вернет функция vla-getInterfaceObject при разных значениях аргументов? как узнать какие свойства и методы могут быть применимы к этому обьекту?

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

Ну вторая-то часть вопроса явно по инерции задана:
(vlax-dum-object shlobj t) вернет тебе все что надо и что не надо
---
Исправляюсь. Ошибся капитально - настолько привык к своим методам и СОМ-серверам, что уже и на остальные тоже распространяю эти подходы...

[Alxd]

В хелпе же написано про vla-getInterfaceObject . Клевая функция. Позволяет создать COM объект in-process, т.е. в одном адресном пространстве (если где-то наврал с терминами - прости).
Объект созданный таким образом работает с AutoCAD'ом намного быстрее, чем созданный через CreateObject, т.к. минует море обходных путей и преобразований.

Например, пишешь ты свое приложение, которое обладает COM интерфейсом. В приложении общаешься с методам AutoCAD типа AddLine. Если создать твое приложение через CreateObject, то оно будет выполняться 60 секунд (например), а если через vla-getInterfaceObject - секунд 6 или даже 0,6.

Попробуй!

[Лентяй]

Может это из пушки по воробьям, но я пользуюсь этим методом, когда надо из АвтоКАДа указать путь к другим фвйлам или фыйлам других приложений. Например, так:

Код:

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

(setq ShellApp (vla-getInterfaceObject acobj "Shell.Application"))
(setq dir (vlax-invoke-method ShellApp 'BrowseForFolder 0 "Select Directory to Look for Files in" 0)))

[Apelsinov]

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

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

[ShaggyDoc]

что за аргумент ProgID у функции vla-getInterfaceObject (тут "Shell.Application" ) какие значения он может принимать? как получить список возможных значений?

ProgID - символьный идентификатор COM-объектов, присваиваемый разработчиками. Например, "AutoCAD.Application.16", "Shell.Application.1". Как придумал автор, так и будет.

По ProgID приложения (в основном сама Windows) разыскивает характеристики COM в реестре.

Например, для "Shell.Application.1" можно установить, что он находится в %SystemRoot%\system32\SHELL32.dll.

"Список возможных значений" для всех объектов находится
в [HKEY_CLASSES_ROOT\CLSID\

Там множество GUID наподобие {13709620-C279-11CE-A49E-444553540000}. У каждого ключа такого типа есть подключ наподобие

HKEY_CLASSES_ROOT\CLSID\{13709620-C279-11CE-A49E-444553540000}\ProgID, а в его значении и записан символьный идентификатор. Если желаете "огласить весь список", надо перебрать реестр. Это и не нужно.

что за объект вернет функция vla-getInterfaceObject при разных значениях аргументов? как узнать какие свойства и методы могут быть применимы к этому обьекту?

Эта функция Автокадовская. Она вернет указатель на объект. Попытаться получить свойства и методы можно через vlax-dump-object. Но толку от этого для программиста мало. Если автор COM-объекта предполагает его использование посторонними, то он должен документировать объект. То есть написать Help. Делать это лень.

Тогда предоставляется .TLB-файл, это библиотека типов в специальном формате. Из нее можно получить описание объектов, свойств и методов для конкретной среды программирования. Например, в Delphi можно импортировать библиотеку типов и получить PAS-файл с интерфейсной частью (реализация, естественно, скрыта).

VisualLISP не относится к "чисто конкретным" системам программирования. В нем такой фокус невозможен. Но можно извлечь описание объектов с помощью сторонних утилит. Хорошие, типа ActiveX Explorer - платные. Есть бесплатные, похуже. Я использую утилиту TypeExport, позволяющую вытаскивать интерфейсы в виде PAS. Например, для Shell.Application это файл на 1164 строки.

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

Импортировать библиотеки типов в LISP совершенно необязательно - это дает только возможность подсветки синтаксиса, как и родных имен функций.

[Alxd]

2 Apelsinov
Не умничать, а пальцем показать? Попробуй так сделать

(setq s (vla-getinterfaceobject (vlax-get-acad-object) "wscript.shell"))
(vlax-invoke-method s 'popup "Yessss!!!")
(vlax-release-object s)

Получишь ласковый "Yessss!!!" в AutoCAD

еще так можно поприкалываться
(setq s2 (vla-getinterfaceobject (vlax-get-acad-object) "WScript.Network"))
(vlax-get-property s2 'ComputerName)
(vlax-release-object s2)

Получишь имя своей тачки в ответ.
Так понятнее?

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

Хочешь описания COM объектов существующих в Windoze - читай MSDN. Их там...

[Apelsinov]

ShaggyDoc
Огромное спасибо!

Alxd
Вот опять написал как все это здорово работает, и т.п. Ну это мне понятно.

Но вот откуда ты узнал-то что есть такое - "wscript.shell" и метод к нему popup ? что есть "WScript.Network" и метод ComputerName ?

читай MSDN

а что это? ты правда думаешь что это надо и можно читать?

-----------------------------------------------------------
теперь такой вопрос:

есть у меня хелп "Руководство по функциям API! и немного "полезняшек" VBA и VBS " где доступно, на русском, есть описания различных функций API.
Я нифига не смыслю в VBA и VBS, но я понял такую вещь, что зная расположение библиотеки (например kernel32.dll) можно легко использовать содержащиеся в ней функции.

можно ли это сделать в лиспе?
То есть я так понял из вышеизложенного ShaggyDoc'ом, что можно, но надо как минимум знать этот ProgID - символьный идентификатор COM-объектов.

PS. Я прошу меня извинить за такие, возможно, глупые вопросы, но я не программист, и как видно, не понимаю элементарных вещей.

[Alxd]

Самый простой способ изучить коллекцию COM объектов установленных у тебя на машине - открыть Excel и нажать Alt+F11 (вызвать VBA editor). Топай в меню Tools->References. Там тааааааааакой список!!! Подключаешь че интересно. Потом закрываешь References и жмешь кнопку на панели инструментов Object Browser. А там разберешься... уверен!

[ShaggyDoc]

Знать расположение kernel32 недостаточно. Подобные библиотеки всегда в одном месте. Да и для вызова из своей программы функции из DLL место ее проживания как раз знать не обязательно.

Чтобы использовать функции из DLL Windows, надо изучать MSDN. Это огромный массив информации. Но, даже найдя требуемую функцию и получив ее описание, обратиться к ней напрямую не так-то просто. Надо уметь работать с WinAPI в своей конкретной среде разработки. Или пользоваться разными "обертками".

Например, в Delphi есть куча модулей, переводящие вызовы к WinAPI в паскалевский синтаксис. Я делал такую цепочку посредников для LISP. Это позволяет "прикладному программисту" не вникать в API.

Есть, например, у меня целая куча функций, выводящих стандартные диалоги (ru-msg-alert, ru-msg-stop и т.п.) . В LISP "прикладной" программист вызывает
(ru-msg-alert "Ошибка"). Выведется диалог, отличающийся от стандартного alert заголовком, текстом и кнопками. На самом деле будет еще запущена низкоуровневая LISP-функция ru-msg-messagebox, она вызовет ru-msg-box-ex, в этой будет сформирован требуемый набор кнопок и иконка, потом будет вызвана функция ru-msg-srv-show, которая запустит COM-сервер ruAxSvr.WinMsg, в котором произойдет вызов к функции Delphi Application.MessageBox. И только из модуля Delphi произойдет вызов "конечной" функции WinAPI.

Этого "дома, который построил Джек" не было бы, если бы в LISP были функции прямого обращения к DLL. Но если бы не было COM, то пришлось бы оставаться наедине с DCL, или с VBA.

Изучать коллекцию COM можно разными способами, в том числе и через Excel. ТОлько надо иметь ввиду, что отображаемые в списках объектов названия не обязательно соответствуют ProgID.

Например "Shell.Application" отображается как "Microsoft Shell Controls And Automation (Version 1.0)".

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

Сообщение от ShaggyDoc ... Но если бы не было COM, то пришлось бы оставаться наедине с DCL, или с VBA...

Ну не все так печально! Есть еще и ObjectARX, который был еще до того, как стало возможным пользоваться COM в AutoLISP.
И кроме того есть еще и arx-файл Мансура Мамкина, который позволяет обращаться из lisp-программ напрямую к DLL.

[ShaggyDoc]

Сообщение от Александр Ривилис Сообщение от ShaggyDoc ... Но если бы не было COM, то пришлось бы оставаться наедине с DCL, или с VBA... Ну не все так печально! Есть еще и ObjectARX, который был еще до того, как стало возможным пользоваться COM в AutoLISP. И кроме того есть еще и arx-файл Мансура Мамкина, который позволяет обращаться из lisp-программ напрямую к DLL.

ObjectARX есть. И будет есть. Особенно если к каждой новой полубете AutoCAD будет новая версия ARX, непременно сделанная в новой версии VS. Махинации MS надоедают. На работе уже полностью перевели разработку на C++ в QT. Хорошего мало, но бесплатно и не зависти от козней "сюзерена".

Упомянул я про VBA исключительно из-за доступности "простому народу", хотя и "такая гадость эта заливная рыба". ObjectARX - для элиты. А нам, сантехникам, что попроще. :cry: По Сеньке и шапка.

ARX Мансура также привязан к версиям. Да еше и к Мансуру. Напоминает ситуацию с ObjectDCL.

Ну, и еще есть штатный путь - RunDLL. Только тут DLL надо особым образом писать. И гораздо проще воспользоваться COM. Здесь хорошо то, что и среда разработки может быть любая, и нет привязки к версиям AutoCAD, да и использовать можно в любых приложениях.

[Alxd]

Не просто

arx-файл Мансура Мамкина

, а приложение MtmdLoadDLL v1.0, которое описано и скачивается отсюда. 8)

ARX Мансура также привязан к версиям. Да еше и к Мансуру. Напоминает ситуацию с ObjectDCL

Чё все так боятся привязки к программеру freelancer'у??? Опасно, да?А вдруг он не захочет поддерживать свой продукт, да? А мотивировать надо... :twisted:

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

[ShaggyDoc]

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

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

А больше всего бесит привязка ARX к конкретным версиям конкретных компиляторов. Это же просто сговор. Будто нельзя сделать ARX(DLL) в любой системе. Ведь это же было в AutoCAD!

[KAI]

А больше всего бесит привязка ARX к конкретным версиям конкретных компиляторов. Это же просто сговор. Будто нельзя сделать ARX(DLL) в любой системе. Ведь это же было в AutoCAD!

Вот именно, за 6 лет уже третья!
Как хорошо, что я пишу только на lisp (практически), не надо постоянно перекомпилировать код.
Но вот и я без DosLib не обошелся, а там тоже не все так гладко, столкнулся с интересной особенностью. Если в 15-16 функция создания папки возвращала путь независимо от того существовал ли этот директорий прежде или нет, то в 17 если директорий существует, функция возвращает nil, странности...

Если я исчезну физически

Тьфу^3 через левое плечо. Еще поживем!