Вот справочник по типам переменных в VB
http://www.codenet.ru/progr/vbasic/bit/Variables.php
Для того, чтобы VBScript адекватно принял дату, ему на выход нужен либо сразу Date, либо Date возвращённый через Variant, как в примере Выше, если отдавать через параметры. Я бы попробовал поэкспериментировать с ним (Date), а потом уж если не сложится, то попробовать универсальный вариант - буфер Byte().
]]>В СИ++ время в секундах с 1970 года передается как LongLong (Это время может быть разным - и 2,365e+9(2045 год), и 1,104e+9 (2005 год))
Получается для хранения таких больших переменных что можно использовать в VB?
Dim outCert As String
err = HCL.X509ExportCertificateFromStore("", 0, outCert)Ну вот сейчас принимаюсь за создание всего кода. Думаю теперь особых проблем не должно быть)
Спасибо большое за советы) Обычно у меня так всегда, нужен небольшой пинок)
ПРИМЕЧАНИЕ
COM старается помещать внутрипроцессные объекты в то же подразделение, что и у создающих их потоков.
Т.е. те, кто помечает свои многопоточные объекты как "free", почему-то не желают, чтобы они создавались в STA. Наверно, просто хотят избежать затрат на системный маршалинг вызовов, который их объектам не нужен.
А вот это мне как-то не приходило в голову:
Даже ThreadingModel=Apartment объекты должны быть "немного потокобезопасными", поскольку ThreadingModel=Apartment не мешает нескольким объектам созданным в одной DLL ссориться из-за разделяемых данных (в случае, если они попадут в разные STA).
Вот ещё важная вещь:
Некоторые программисты используют локальную память потока (TLS) как временное хранилище данных. Предположим, вы реализуете COM метод и вам нужно сохранить некоторую информацию о текущем вызове и которая понадобится при следующем вызове. Вы можете воспользоваться TLS. И в STA это будет работать. Но если объект, который вы пишете находится в MTA, вы должны избегать TLS как чумы.
Почему? Потому что вызов, попадающий в MTA перемещается в RPC потоки. Каждый вызов запросто может попасть в различные RPC потоки, даже если все они были из одного потока и одного и того же подразделения. Поток B не имеет доступа к локальной памяти потока A, так что если вызов номер 1 попадает в поток A и объект помещает данные в TLS, то если вызов номер 2 попадает в поток B и объект пытается получить данные записанные в TLS при первом вызове, он их не получит. Никак.
Избегайте использовать TLS для сохранения данных между вызовами MTA-шных объектов. Это будет работать, только если все вызовы придут из одного и того же объекта и из того же самого MTA, в котором находится объект.
У меня в TLS может храниться код последней ошибки, возвращаемый вызовом GetLastError после вызова API-функции. Его потом можно запросить, вызвав метод LastError.
Конечно, в VBS и JS, выполняемых Windows Script Host, DWX в MTA не попадёт. Но теоретически, т.к. он вообще-то потокобезопасный (2-я версия), где-то и когда-то может попасть. При этом, правда, ещё надо, чтобы его вызывали из STA. Довольно сложный сценарий.
]]>Вот тут хорошо расписано. Я даже вроде бы понял. ) Хотел коротко пояснить, но чую, что буду дублировать статью.
]]>Хотя я тут, похоже, не знаю каких-то тонкостей, т.к. не понимаю, зачем нужна поточная модель "both". Казалось бы, если объект многопоточный, то и шабаш. Чего ещё надо-то? Зачем специально указывать ещё и возможность работы в однопоточном апартменте? Что-то тут нечисто. Казалось бы это само собой разумеется, но нет, зачем-то указывают. Какую способность объекта это предполагает? Непонятно. 
]]>По идее должен создаться наш компонент оболочки, если описание в ветках реестра не противоречит описанию объекта внутри DLL.
Насчёт
REFIID riid, // Ссылка на интерфейс связанный с объектомуточню, что тут передаётся ID нужного интерфейса ClassFactory (есть просто IClassFactory и есть более продвинутый IClassFactory2), а не интерфейса того объекта, чей ID в rclsid. Интерфейс объекта запрашивается уже потом, в методе CreateInstance.
]]>А здесь-то она зарегистрирована, так что ситуация другая. Имитировать наличие записей в реестре не нужно.
Да, библиотека то зарегистрирована, но пути то тогда будут смотреть на подменённую DLL ? Но если создавать, как Вы говорите, то получается при этом можно как-то напрямую указывать путь до нужного DLL ?
Не совсем понимаю как, если
STDAPI DllGetClassObject
(
REFCLSID rclsid, // Уникальный идентификатор объекта
REFIID riid, // Ссылка на интерфейс связанный с объектом
LPVOID * ppv // адрес переменной которая получит интерфейс
);
Функция на вход же принимает rclsid ?
Попробую более подробно пояснить, что мне пока непонятно.
Представим:
У нас имеется некая COM.dll, сделанная сторонним разработчиком (будем называть её сторонняя).
Мы делаем свою COM.dll обёртку (будем называть её наша)
Изначально регистрируем стороннюю COM.dll через regsvr32.
Получаем в реестре некие записи:
HKEY_CLASSES_ROOT\COM.Object\CLSID c параметром REG_SZ и некоторым классидом (Например:{0E57F1D5-1FСE-11D0-8FF2-00A0В10018BC})
и
HKEY_CLASSES_ROOT\CLSID\{0E57F1D5-1FСE-11D0-8FF2-00A0В10018BC}
в которой несколько подразделов отвечающих за информацию о компоненте в числе которых подраздел InProcServer32, который содержит параметр по умолчанию REG_SZ с путём до зарегистрированной DLL - (например:C:\MyActiveX\COM.dll)
Теперь мы берём и подменяем зарегистрированную DLL на нашу, а исходную называем COM1.dll
Получаем:
C:\MyActiveX\COM.dll - наша DLL
C:\MyActiveX\COM1.dll - переименованная сторонняя DLL
Теперь, к примеру, в скрипте выполняем CreateObject("COM.Object")
По идее должен создаться наш компонент оболочки, если описание в ветках реестра не противоречит описанию объекта внутри DLL.
Далее, как Вы говорите, мы должны вызвать DllGetClassObject ? Я пока не имел опыта работы с ней и сейчас поиск в гугл не дал мне понятного ответа.
Но я так понимаю, что она должна обратиться в реестр для получения информации по переданному classid-у, а там путь, указывающий на "C:\MyActiveX\COM.dll". Т.е на нашу DLL ?
Или всё работает иначе и я ошибаюсь ?
(*) Ааа.... Кажется понял...
Первым делом вызывается CoLoadLibrary или LoadLibrary для подгрузки библиотеки в память, далее получаем указатель на экспортируемую DllGetClassObject и передаём ей классид создаваемого объекта ? И по идее ей тогда в реестр обращаться нет нужды ?
]]>создание условий при которых VB "думает" что библиотека зарегистрирована.
А здесь-то она зарегистрирована, так что ситуация другая. Имитировать наличие записей в реестре не нужно. VBS всего лишь запросит IDispatch, который обёртка ему и выдаст. А основной объект создаст сама. Механизм, описанный мной, работает, мне ведь пришлось его реализовывать в DWX. Никаких шорткатов от системы я не использовал. IClassFactory, IUnknown, IDispatch — всё ручной работы.
Так для этого же dll и экспортирует функцию DllGetClassObject. Из неё получаем объект ClassFactory и создаём объект нужного класса методом CreateInstance. То же самое делает CoCreateInstance.
Кривить душой не буду. Сам не пробовал. )) Возможно и так как Вы говорите можно реализовать.
Порылся на форуме, нашёл - http://bbs.vbstreets.ru/viewtopic.php?f=28&t=45527. Вроде бы оно
Если открыть архив, то в коде модуля modTrickUnregControl.bas, автор пишет:
' Функция перехвата CLSIDFromProgID
' При передаче нашего ProgID мы обманываем вызывающую сторону, делая вид что в реестре есть запись HKCR\CLSID\ProgID\CLSID' Функция перехвата CoGetClassObject
' Здесь мы создаем объект (обычно фабрики классов), используя не запись в реестра, а переданные параметры для имени библиотеки' Функция перехвата OleRegGetMiscStatus
' Здесь мы обманываем вызывающую строну, делая вид что в реестре есть запись HKCR\CLSID\MiscStatus и подсовываем ей свой' Функция перехвата RegQueryValue
' Здесь мы обманываем вызывающую строну, делая вид что в реестре есть записи HKCR\CLSID\(TypeLib, InprocServer32, Version) и подсовываем ей свой
Вот об этом я и вспомнил. )
]]>Тогда возникает вопрос как создавать инстанс исходного компонента в оболочке ). Ведь обычный вызов CoCreateInstance обратится в реестр, там найдёт путь до DLL и попробует создать её от туда, а там лежит наша DLL. )
Так для этого же dll и экспортирует функцию DllGetClassObject. Из неё получаем объект ClassFactory и создаём объект нужного класса методом CreateInstance. То же самое делает CoCreateInstance.
Помню был вариант на форуме VBStreets. Приходилось делать хук - перехват API, подменять данные...
Хотя, может, там всё же что-то другое было.