Prev: restart a process in XP ..
Next: Handling Events in a VBScript Class
From: mr_unreliable on 3 Jul 2008 13:28
I know what you're thinking. If microsoft wanted scripters to
be calling api's from script, then they would have built that
capability into the scripting engine. And besides, isn't there
already a DynaWrap utility for those who would dare to trespass
outside the boundaries of accepted scripting norms? True...

However, (for the sake of completeness?), while browsing in
the PowerBasic forum, I stumbled across a posting authored
by Charles Pegge and entitled: "How to turn a DLL into
a COM object", found here:

http://www.powerbasic.com/support/pbforums/showthread.php?s=69fab519eedc80eb6974c2c9ba8c881b&t=28421&highlight=comfordll

That sounded intriguing. And it was. What you get is some
powerbasic source code, a dll and a typelib. You register
the dll (and the typelib) with the provided bat file. Then
you run the script, which will interface with a "standard"
dll (also provided). It all works like "a charm" (any win98
users, see the postscript). The implication is that if
"COMforDLL" will work with a standard dll, then it will work
with any standard system dll as well.

What was intriguing to me was the notion that you could write
a com component in powerbasic, whereas the conventional wisdom
is that microsoft vb or c++ (and templates) are necessary.
The "basic" source code provided, (if you take the time to
read it), looks just like c++ code albeit written in basic.
In other words, it is more-or-less c++ code rendered into
the basic language. If nothing else, it is helpful to
understand if one eventually wished to go from vb to c++
in order to write some actX objects which don't render
very well into vb.

Here is the vbs test script provided by Pegge:

--- <code> ---
' VBscript .vbs, Author: Charles E V Pegge, 30 June 2006

set II = WScript.CreateObject("COMforDLL.Object","II_")

MyLibrary = II.LoadLibrary ( "ExampleHostDLL.dll" )

ReqReturnString = II.GetProcAddress ( MyLibrary,
"TestFunctionReturnString" )

CallMeBack = II.GetProcAddress ( MyLibrary, "CallMeBack" )
'MsgBox CallMeBack, 0, "CallMeBack handle"

'some test data
a=1:b=2:c=3:d=4:e=5:f=6:g="seven":h=8

if ReqReturnString then
result = II.fun ( ReqReturnString, a,b,c,"four",e,f,g,h )
MsgBox result, 0, "Result"
end if

II.RequestCallback(3) 'a COmforDLL test function

if CallMeBack then
II.EnableLibraryCallbacks (MyLibrary)
II.fun CallMeBack, 2
II.DisableLibraryCallbacks (MyLibrary)
end if

FreeLibrary = II.FreeLibrary (MyLibrary)
Set II = Nothing


sub II_Callback1()
Wscript.echo "Callback 1 is called"
end sub

sub II_Callback2(v1,v2,v3,v4)
Wscript.echo "Callback 2 is called",v1,v2,v3,v4
end sub

sub II_Callback3(v1,v2,v3,v4)
Wscript.echo "Callback 3 is called",v1,v2,v3,v4
end sub
--- </code> ---

As you can tell from the code, the COMforDLL utility is
nothing more than a wrapper for the "LoadLibrary" api,
"GetProcAddress" api, some call-the-function code, and
then the "FreeLibrary" api, the basic mechanics of calling
a system api. DynaWrap does a better job of hiding the
guts of the api call, but then COMforDLL does get
the job done.

cheers, jw

p.s. Note for the win98 crowd. My first attempt to
register the COMforDLL dll and typelib with the win98
regsvr32.exe failed. How revolting! I took the package
over to a nearby winXP system and it worked perfectly.
And so, I thought that maybe I could get COMforDLL to
work with win98 if I manually copied the winXP registry
entries and took them back to win98. So I exported the
entries from winXP and loaded them into the win98
registry. VOILA! Now the COMforDLL works successfully
on win98 too. If there are any win98 aficionados left,
then the reg file I used is attached.
 | 
Pages: 1
Prev: restart a process in XP ..
Next: Handling Events in a VBScript Class