DLL Registration Problem

[Brian Kurtyka]

Okay, here's my problem. I compile various dll's in PB. (Like the vbsort example, my own tests, ect.) They all work when being called by a PB program but when I try to open them using through the "References" area in VB I get "Can't add a reference to the specified file". I also get an error when I try to register the DLL and I think the problems are connected.

When I try to use regsvr32 I've copied the file into win/sys and type "regsvr32 vbsort.dll". The following error box appears: "vbsort.dll was loaded, but the DLLRegisterServer entry point was not found. DLLRegisterServer may not be exported, or a corrupt version of vbsort.dll may be in memory. Consider using PView to detect and remove it."

All I want to do is call my function from VB. PLZ HELP!

Brian

[Wayne Diamond]

hi brian,
you dont use references to call a pb dll from vb, you declare it in your vb source code.
theres a simple example here

best of luck,
wayne


------------------

[Brian Kurtyka]

That's true, I was just happened to notice that using the References area returned that error.

After I posted the message I finished searching throug the entire archive. Last year someone had the same problem. Their solution didn't fix my problem and I think I know why. I have two NIC's in my machine. I tested it from another machine on my LAN with only one NIC and it works fine.

Does anyone know a workaround for this problem? I would really like to use the program from my primary machine.

Thanks,
Brian

[Wayne Diamond]

Can you be more specific? You seem to be talking about two different issues in both of your posts so Im a bit confused
*wonders if you're referring to TCP LISTEN only being able to bind to one adapter*

------------------

[Lance Edmonds]

TCP LISTEN? Is that an API function, Wayne? It is not part of PowerBASIC.

REGSVR32 is used for registering COM/ACTIVE/OCX's with Windows. PowerBASIC creates "standard" DLL's which do not need (and are not able) to be registered.

As Wayne points out, you just need to DECLARE the exported DLL Subs and Functions in VB in order to use them.

The most common problem is usually capitalization of the exported name, which is solved with the use of an ALIAS clause in both the DLL code and the VB declare, thus:

' PB code
#COMPILE DLL "MYDLL.DLL"
SUB MySub ALIAS "MySub" () EXPORT 
...
END SUB
 
' VB code
DECLARE SUB MySub LIB "MYDLL.DLL" ALIAS "MySub" () 
...
CALL MySub

Basically, unless the PB code contains an ALIAS statement, the Sub/Function is exported with the name CAPITALIZED. VB works a little differently in this case, but it will work if you capitalize the sub/function name in the declare there. For example:

' PB code
#COMPILE DLL "MYDLL.DLL"
SUB MySub () EXPORT ' no ALIAS, exported name is "MYSUB"
...
END SUB
 
' VB code
DECLARE SUB MYSUB LIB "MYDLL.DLL" () ' imported name is case sensitive in VB
...
CALL MYSUB

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Brian Kurtyka]

Thank you for your replys. Here is the current situation:
- Now that I know you don't have to register the DLL, that's helps thing out a bit.
- I'm still getting an error 57 despite using alias or being case sensative.

Is there any way to not have this problem while having two NIC's?

Brian

[Tom Hanlin]

I take it we've moved on to a new problem? Error 57 is "device I/O error",
which is an error on a hardware device. This is unlikely to be at all
related to your DLL declarations. I suppose it could be related to having
two NICs, if your program is doing something with the NICs...?

Perhaps you could explain where the error 57 is coming from?

------------------
Tom Hanlin
PowerBASIC Staff