|
Subject:
|
Creating a DLL using VB
|
|
Posted By:
|
gisvb
|
Post Date:
|
12/30/2003 12:22:00 PM
|
I would like to create a DLL using VB, but NOT CREATING a Class, which forces invokation of the routines/functions stored in the DLL to be called as methods of a "ficticious" class. Rather, I would like to create my functions as standard functions in standard modules, so when called they are called as if they were normal VB functions
Is it possible? And, if so, how?
thanks
gisvb
|
|
Reply By:
|
Yehuda
|
Reply Date:
|
12/30/2003 12:42:01 PM
|
You can set your class to global multiuse. A class that is global multiuse does not require instantiation.
|
|
Reply By:
|
gisvb
|
Reply Date:
|
12/30/2003 1:48:48 PM
|
thanks, after tiding my code, the invokation of a function stored in a dll crashes because it can not find the "entry point"
I am using VBA as main language, and the dll has been built using VB Studio 6... I am using a simple function like
public function multiplicar(a as double, b as double) as double
multiplicar=a*b
end function
Any suggestions for that ?
thanks
|
|
Reply By:
|
Yehuda
|
Reply Date:
|
12/30/2003 2:29:20 PM
|
I assume you are working off a dll that has a globalmultiuse class. Try creating a new Dll with the same functions (cut and paste). It may be when switching over the dll went flaky.
|
|
Reply By:
|
gisvb
|
Reply Date:
|
12/30/2003 4:07:43 PM
|
thanks. I tried creating from scratch, but it can find the entry point.
It should be some basic error on my side, since all the stuff is very simple, but I must have missed something.
Anyway, the VBEditor recognizes de function, because when writing the name and the opening parenthesis it shows (in a tip) the arguments, so...... but at run time something happens.....
Any suggestions on that?
thanks again
|
|
Reply By:
|
gisvb
|
Reply Date:
|
12/30/2003 4:39:16 PM
|
Does anyone know how to "extract" the function names contained in a dll?. I have read that the exported names in a dll might have suffixes added to the function names,... so maybe I have to check now what function names/entry points my dll has....
|
|
Reply By:
|
Yehuda
|
Reply Date:
|
12/31/2003 10:00:02 AM
|
You said a new dll can find the entry point. Is this a typo? If not, why not just go with the new dll?
|
|
Reply By:
|
gisvb
|
Reply Date:
|
1/1/2004 4:22:12 PM
|
sorry, yes, it was a typo.... Entry Point CANNOT be found, so I am stuck here, without knowing what more to test... maybe registering through regsvr32???
|
|
Reply By:
|
Yehuda
|
Reply Date:
|
1/1/2004 5:52:48 PM
|
If you have not registered, then do so. Regardless of whether you are going to instantiate the DLL it still needs to be registered.
|
|
Reply By:
|
gisvb
|
Reply Date:
|
1/2/2004 2:00:10 PM
|
I registered the dll successfully, but running the program again, crashes as usual because it is unable to find the entry point
Has to be something basic that I am doing wrong, or my computer has a strange setup somewhere...???
|
|
Reply By:
|
gisvb
|
Reply Date:
|
1/2/2004 3:19:22 PM
|
I noticed another thing
If the program that calls the dll contains a
Public Declare Function multiplicar Lib "proyecto1.dll" _
(x As Double, y As Double) As Double
the error is 453 (cannot find the entry point "multiplicar"
if I comment the Declare statement out, the error becomes
430, this class doesn't admitt Automation or doesn't addmit the expected interface (or something similar, I am translating from Spanish)
Does it help in getting some light in the problem?
thanks
|
|
Reply By:
|
gisvb
|
Reply Date:
|
1/2/2004 4:29:15 PM
|
It already works.
It was my fault, the reference in the VB code pointed to an old version of the dll, ... I have referenced it back and works as expected...
anyway, using the Public Declare .... still doesn't find the entry point, but doesn't matter, because without that statement it works anyway....
sorry for any inconvenience caused by this stupid mistake of my own
|
