This is a multi-part message in MIME format.
--------------050203010807070203050001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
--------------050203010807070203050001
Content-Type: text/plain;
name="COMforDLL.reg.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="COMforDLL.reg.txt"
REGEDIT4
; COMforDLL registry entries, jw 02July08
; The "COMforDLL" utility comes with an actX dll plus a typelib,
; and a batch file to register these two entities. But alas,
; couldn't get that to work (i.e., register itself) on win98se.
; And so, found an accomodating winXP system, and VOILA! it did
; work over there. And so, exported the registry entries, and
; then attempted to load them into the win98se registry as follows:
; ------------------------------------------------
[HKEY_CLASSES_ROOT\COMforDLL.Object]
@="Intermediary between DLL host and COM client"
[HKEY_CLASSES_ROOT\COMforDLL.Object\CLSID]
@="{044A4BF7-837E-459A-A9AA-C961B8888E80}"
[HKEY_CLASSES_ROOT\CLSID\{044A4BF7-837E-459A-A9AA-C961B8888E80}]
@="Intermediary between DLL host and COM client"
[HKEY_CLASSES_ROOT\CLSID\{044A4BF7-837E-459A-A9AA-C961B8888E80}\InprocServer32]
@="C:\\Program Files\\COMforDLL\\COMforDLL.dll"
"ThreadingModel"="both"
[HKEY_CLASSES_ROOT\CLSID\{044A4BF7-837E-459A-A9AA-C961B8888E80}\ProgID]
@="COMforDLL.Object"
--------------050203010807070203050001--