Сможет ли кто-нибудь объяснить (желательно как для тупых) каким образом можно управлять объектами Office (Word, Exel, и т.п.)
Задача — создать ActiveX dll, на основе ATL (или иначе, но чтобы не надо было тащить с собой MFC)
Чтобы использовать можно было из VBA, например:
Set appdll=New APPDLL.Class1
appdll.HangeSize Me 'где Me -форма в VBE
соответственно в dll по этому методу допустим меняется размер формы(или другое свойство)
Сделать подобное на VB -5секунд, но опять же потом требуется vb-библиотека, да и скорость при некоторых задачах
Доступные мне примеры работают так: запускается VC программа, а из нее создается документ Office и тд, причем в основном на основе MFC :(
Мне же надо наоборот — главным идет VBA
Пытался разобраться по статье "Директива #import" — но увы, с ATL проэктом не катит- куча ошибок на создаваемый *.tlh
Только просьба, по существу, советы "прочитай книгу ...." — не надо, я бы это сделал, но в радиусе 500 км таких книг нету :(
Если у кого есть пример, скиньте на мыло oldpasp@mail.ru
И еще, здесь часто есть ссылка на optim.ru — никак не могу попасть, она работает?
Здравствуйте Oldpasp, Вы писали:
O>Сможет ли кто-нибудь объяснить (желательно как для тупых) каким образом можно управлять объектами Office (Word, Exel, и т.п.) O>Задача — создать ActiveX dll, на основе ATL (или иначе, но чтобы не надо было тащить с собой MFC) O>Чтобы использовать можно было из VBA, например:
O>Set appdll=New APPDLL.Class1
А в VBA есть типизированные объекты? Вроде, нет, все через дисп.
O>appdll.HangeSize Me 'где Me -форма в VBE
O>соответственно в dll по этому методу допустим меняется размер формы(или другое свойство)
O>Сделать подобное на VB -5секунд, но опять же потом требуется vb-библиотека, да и скорость при некоторых задачах
Я не очень понял, что тебе надо. Из VBA вызывать программу, которая будет работать с экселем через автоматизацию? А почему не работать с экселем напрямую? И откуда VBA узнает про "форму в VBE"?
Но если ты имеешь код на VB (не VBA, компилируемый), то перевести в C++/ATL его можно автоматически. Главное — директива #import, дуальные интерфейсы и внимательно следить за типами в интерфейсах.
O>Пытался разобраться по статье "Директива #import" — но увы, с ATL проэктом не катит- куча ошибок на создаваемый *.tlh
Ну, давай начинать с первой непонятной. Show me the code.
O>Только просьба, по существу, советы "прочитай книгу ...." — не надо, я бы это сделал, но в радиусе 500 км таких книг нету
Здравствуйте George_Seryakov
GS> А в VBA есть типизированные объекты? Вроде, нет, все через дисп.
Да по мне то хоть через что, лишь бы выполняла свои функции и требовала минимальных действий при установке и использовании. Я уже примерно понял, что через интерфейсы :), вопрос — как
GS> Я не очень понял, что тебе надо. Из VBA вызывать программу, которая будет работать с экселем через автоматизацию? А почему не работать с экселем напрямую? И откуда VBA узнает про "форму в VBE"?
не будем применять термин VBE — так как сам не до конца разобрался, чем он отличается от VBA :)
Задача: в среде Word,Exel,Access (мне кажется это не принципиально, механизм должен быть одинаковым) открываем Документ(Форму, Лист). Пусть будет Форма (UserForm) с кнопочкой
По нажатию "кнопочки" изменяется размер формы и цвет фона.
Разумеется, сделать это (и многое другое) в среде VBA и VB поверьте, для меня не составляет практически никаких трудностей.
Вопрос — как свести это дело в DLL — (не VB-шную, а скажем "чистая, Windows-ая dll")
Эта задача лишь пример, в самом деле может потребоваться большой объем вычислений или работы с Windows
Думаю будет верным утверждать, что большинство программных продуктов у широкого пользователя (нормального, не "сдвинутого" на компьютере) — использует или широко поддерживает среду VBA
А если ряд есть ряд действий, операций, часто используемых — то почему бы не вынести в DLL
GS> Но если ты имеешь код на VB (не VBA, компилируемый), то перевести в C++/ATL его можно автоматически.
Хорошо, пусть будет VB
Я ведь про то и спрашиваю, как перевести на C++/ATL
Конечно, это наверняка долго объяснять, поэтому, если есть пример работы с объектами VB(VBA) в C++/ATL- DLL — обращаю внимание, не создаваемыми в процедурах DLL, а УЖЕ СУЩЕСТВУЮЩИМИ, т.е. вызов методов происходит из среды VB(VBA) с передачей в качестве аргумента ссылку на объект — буду весьма признателен за ссылку или за посылку :)
GS>Ну, давай начинать с первой непонятной. Show me the code.
Со статьей разобрался, просто для использования #import библиотеки Assess2000 надо еще делать импорт ADO (в статье сделан только DAO)
GS>MSDN?
Много лет пытались меня выучить немецкому, так что конечно можно и это, только если стиль не сильно литературный :)
Наверное не надо уже пояснять, что я только начал разбираться и поставил цель не разрабатывать собственные полнофункциональные приложения (на хлеб с маслом и так пока хватает), а создавать дополнения к уже существующим.(Лень мне тащить огромные куски кода из документа в документ)
Здравствуйте Oldpasp, Вы писали:
O>Задача: в среде Word,Exel,Access (мне кажется это не принципиально, механизм должен быть одинаковым) открываем Документ(Форму, Лист). Пусть будет Форма (UserForm) с кнопочкой O>По нажатию "кнопочки" изменяется размер формы и цвет фона. O>Разумеется, сделать это (и многое другое) в среде VBA и VB поверьте, для меня не составляет практически никаких трудностей. O>Вопрос — как свести это дело в DLL — (не VB-шную, а скажем "чистая, Windows-ая dll")
и особенно примеры в конце .
Или проблема, как такой код вызвать из VBA? Делать интерфейсы дуальными.
O>Я ведь про то и спрашиваю, как перевести на C++/ATL O>Конечно, это наверняка долго объяснять, поэтому, если есть пример работы с объектами VB(VBA) в C++/ATL- DLL — обращаю внимание, не создаваемыми в процедурах DLL, а УЖЕ СУЩЕСТВУЮЩИМИ, т.е. вызов методов происходит из среды VB(VBA) с передачей в качестве аргумента ссылку на объект — буду весьма признателен за ссылку или за посылку :)
У тебя есть DLL написанное на VB, значит есть и IDL. Его можно увидеть, посмотрев на DLL с помощью OleView. Вот это IDL и нужно воспроизвести в ATL-ном коде.
При передаче объекта из VBA в С++ код можно передавать через IDispatch*. Просто VBA все объекты держит нетипизированными и работает с ними через Invoke. В С++ коде ты уже можешь сделать QI на типизированный объект и дальше работать с типами, полученными через #import.
Я сейчас не могу сообразить — можно ли использовать вызовы с типизированными объектами в интерфейсах, сделает ли VBA при вызове QI. Возможно, да. Посмотри IDL от своей VB-шной DLL-и, там правильно.
O>Наверное не надо уже пояснять, что я только начал разбираться и поставил цель не разрабатывать собственные полнофункциональные приложения (на хлеб с маслом и так пока хватает), а создавать дополнения к уже существующим.(Лень мне тащить огромные куски кода из документа в документ)
Зачем тогда C++/ATL? Васик и флаг в руки. Серьезно.
Спасибо, направление примерно понятно, будем копать
В статье про "#import" и других примерах меня больше всего смущает вот эта строка:
_ApplicationPtr excel("Excel.Application");//запускается новый экземпляр Exel
или
_Application app;
app.CreateDispatch("Excel.Application");
Как можно получить указатель на приложение-текущего хозяина DLL (с учетом того, что запущено несколько одинаковых "Excel.Application"
Все остальное тогда можно решить.
>Зачем тогда C++/ATL? Васик и флаг в руки. Серьезно.
А спортивный интерес
Серьезно:
Да я бы и особо не полез, но есть несколько контролов и пр. приблуд (с исходниками — VB), которые красиво работают в программах VB, но тормозятся при использовании в VBA одна из причин (как мне кажется) — слишком медленная обработка оконных сообщений.
Да и некоторые VC — контролы некорректно работают в VBA, что не есть порядок.
Здравствуйте Oldpasp, Вы писали:
O>Как можно получить указатель на приложение-текущего хозяина DLL (с учетом того, что запущено несколько одинаковых "Excel.Application"
Передать какой-нибудь объект в DLL и пойти по ссылкам до Application.
>>Зачем тогда C++/ATL? Васик и флаг в руки. Серьезно.
O>А спортивный интерес
Тогда MSDN. Все остальное — сделать и забыть.
O>С важением
George_Seryakov, спасибо, что не оставили без внимания, дальнейшее прошу не воспринимать.
Судя по откликам эта задача либо ну совсем простая, либо "ноу-хау", либо я не один такой глупый.
Самый распространенный ответ на форумах- "почитай MSDN" — мне кажется это знает каждый, кто решился первый раз запустить среду разработки.
Второй по распространенности — "почитай книгу...." — но ведь не увсех есть возможность приобрести книги, Россия- она большая.
Я пока не владею "профессиональной" терминологией, поэтому наверное вопросы большинству непонятны.
Здравствуйте frogge, Вы писали:
F>Здравствуйте George_Seryakov, Вы писали:
GS>> А в VBA есть типизированные объекты? Вроде, нет, все через дисп.
F>В VBA есть, и прекрасно себя чуствуют, вот в VB Script их нет.
Воистину так. Пошел и нашел References в Экселе. А я, недогадливый, так и писал в эксельном VB как в VBS...
Ну тогда проблема с передачей объекта в ATL-ный код очевидна. Пишется IDL, с котором importlib-аются нужные интерфейсы. Строится интерфейс, имеющий в качестве входно параметра указатель на интерфейс передаваемого объекта. Внутри ATL/C++-ного кода импортируются те же самые DLL-и (да, импортировать надо два раза), и сгененерированными при импорте типами переданные объекты успешно хендлаются.
Но в ASP типизации ведь нет? Я не совсем clueless?
