Если эта dll не ActiveX, то делается вызов oSys.Call("lib.dll::Function") экпортируемой функции.
1.Тогда в чем смысл AkelPad.SendMessage? Это ведь точная копия oSys.Call("user32::SendMessage"+_TCHAR)
2.Так:
Code: Select all
AkelPad.Library("my_user32_proxy")
my_user32_proxy.SetWindowText(hwnd, "Hello")
vs
Code: Select all
var oSys = AkelPad.SystemFunction();
var str = "Hello"
var mem = AkelPad.MemAlloc((str.length+1)*_TSIZE/*и не факт что хватит*/);
AkelPad.MemCopy(mem, str, _TSTR);
oSys.Call("user32::Sleep",hwnd,mem);
AkelPad.MemFree(mem);
3. Доступ к кое-какому API я уже третий раз пытаюсь сделать - не получается. Получается такая трудночитаемая простыня, что я сразу его тру с концами.
Если эта dll ActiveX, то делается регистрация и ее загрузка с помощью ActiveXObject.
А вот из AkelPad-а делать второй IE я не стал бы.
И по моему проще написать одну функцию
Code: Select all
const EXPORTED_SYMBOL_STRUCT* WINAPI __declspec(dllexport) GetSymbols(const AKELPAD_SITE* pSite);
чем реализовать ActiveX объект(даже учитывая всевозможные фреймворки типа ATL). Я лично предпочитаю не связываться с COM без крайней необходимости.
ЗЫ: А в скрипте создать поток(oSys.Call("kernel32::CreateThread")) у меня вообще не получилось, а если и создался, то дождаться его используя WFSO не получалось ни разу. Может это потому что g_CurSysCallback->objFunction->lpVtbl->Invoke всегда выполняется в одном и том же потоке?