Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Can't Find Entry Point while using self-created VB DLL

raynaldraynald Member Posts: 5
I am new to VB. I am trying to create a Visual Basic DLL program. I placed my code for DLL into the VB "Module". As I don't intend to create a class, so there is no code in my "Class Module".

In my "module", the following is my code

Public Sub Test()
MsgBox "Test function call"
End Sub

I have compiled the DLL without any problem. However, when I try to use the DLL in a Second, Standard VB project, by declaring

Private Declare Sub Test Lib "c:TestDLL_FolderTestDLL.dll" ()

at the top of Second VB code.

Each time, the Test function is called using

call Test

I will encounter a error message that says

Can't find DLL entry point Test in "c:TestDLL_FolderTestDLL.dll"

Do anyone know what happen?

Thanks in advance

Comments

  • BitByBit_ThorBitByBit_Thor Member Posts: 2,444
    : I am new to VB. I am trying to create a Visual Basic DLL program. I
    : placed my code for DLL into the VB "Module". As I don't intend to
    : create a class, so there is no code in my "Class Module".
    :
    : In my "module", the following is my code
    :
    : Public Sub Test()
    : MsgBox "Test function call"
    : End Sub
    :
    : I have compiled the DLL without any problem. However, when I try to
    : use the DLL in a Second, Standard VB project, by declaring
    :
    : Private Declare Sub Test Lib "c:TestDLL_FolderTestDLL.dll" ()
    :
    : at the top of Second VB code.
    :
    : Each time, the Test function is called using
    :
    : call Test
    :
    : I will encounter a error message that says
    :
    : Can't find DLL entry point Test in "c:TestDLL_FolderTestDLL.dll"
    :
    : Do anyone know what happen?
    :
    : Thanks in advance
    :

    The Declare statement does not work for VB DLL's, which are COM-dll's. They work for the Windows API DLL files (and others). They are written in C/C++ and functions therein are 'exported' so that other applications can use them. In VB it's only possible to write COM DLL's, which means that you always need to work with classes.
    What you want to do is add a Class, call it something like Globals, and set it's Instancing to Global Multi-use. Then add a reference to the DLL in your other project and then you can use your function Test without having to use Declare.

    Best Regards,
    Richard

    The way I see it... Well, it's all pretty blurry
  • eladkarakoeladkarako Member Posts: 2
    - the aforementioned reply is incorrect. -

    how to fix your dll:
    (how to build a proper vb6 dll).

    start new project of vb dll, add reference to "COM+ Services Type Library".

    finish your stuff making sure you have made the function/sub needed to be used as PUBLIC (!)

    save the project, create a dll.
    quit.

    open a CMD console (windows xp's "dos") and browse to the folder of the dll-project. say your project's name(or dll name) is mylib123.dll.
    run this command:
    regsvr32 mylib123.dll

    you will get a note that the dll has been registered successfully.

    open a new project (regular exe that will use the functions/subs from the dll).

    add reference->browse your dll->press ok.

    in your project (say your class inside the dll called myclass1),
    write anywhere:

    dim mc as myclass1
    set mc = New myclass1

    now you can use ANY functions
    (say you have a public function called funcABC that look like that:
    Public Function funcABC (byref s as String) AS String ).

    you can use it like this:
    mc.funcABC "hello"

    ..or to get the function's output:
    msgbox mc.funcABC("world")

    after you've finished, if you've got inner functions in the dll to clean stuff up, then run it, and also run:
    Set ms = Nothing


    why this is working:
    the command you've write down in the CMD is registering the dll using windows's registry (this is the proper way to use dll!). this way you can place the dll in long path location, which involve different letters (not necessarily in english) and it will be fine.

    you can download many examples if you search "how to vb6 dll" in google, or PlanetSourceCode website.

    respectfully,
    Elad Karako ,
    Israel.


  • BitByBit_ThorBitByBit_Thor Member Posts: 2,444
    : - the aforementioned reply is incorrect. -
    :

    Actually, the aforementioned reply, which happens to be mine, is entirely correct.

    You're confusing DLL function exports with Visual Basic's COM class exports.
    The process you are describing here is exactly as I suggested in my reply, only then in less code and more words. What you are doing is creating a VB COM Dll. In VB it's impossible to create standard DLLs such as shell32.dll etc.


    : start new project of vb dll, add reference to "COM+ Services Type
    : Library".
    :

    This is actually not necessary in VB6.

    : open a CMD console (windows xp's "dos") and browse to the folder of
    : the dll-project. say your project's name(or dll name) is
    : mylib123.dll.
    : run this command:
    : regsvr32 mylib123.dll
    :
    : you will get a note that the dll has been registered successfully.

    This process of using the regsvr32 to initiate the Dll Self-register functionality is actually done at compile time by VB6. When you compile a custom DLL, a link to your dll is added to the reference list. Only when deploying the binaries on other pc's (also known as 'installing') do you need to handle proper registering of your dlls, but this is usually handled by the installer you create for your application.


    So the general point I am trying to make here is:
    There are (for the sake of this discussion) two different types of DLLs:
    1) Windows native DLLs, which are functional in nature, and which export functions. Examples are all the API dlls, such as shell32 etc. These types of DLLs can be [b]used[/b] by VB by using the Declare statement, but they can [b]not[/b] be created
    2) COM Dlls, which expose classes/interfaces. This is 'the' VB DLL, and can be created in the way you described. These can only be used by languages that support COM. They are object/interface based, and they do not export functions, but classes and methods.

    I hope the difference is clear now.
    Best Regards,
    Richard

    The way I see it... Well, it's all pretty blurry
  • eladkarakoeladkarako Member Posts: 2
    That is Correct. I do suggest a Com+ rather then API declaration, since most of the time using this regimen demand the dll to be pre-registered anyway, such as OCXs and DLLs in the /System32 Folder. Notice that regarding external Lib. files (any) IN VB6 (!)- this declaration is obsolete since the allocation of VBO Lib. does not always finds the Entry Point in Exported functions, Problem that does not exist in COM type libraries, which has the default File Offset in Win32 SubSystem, that WILL scan Entry Point (+File Offset..until the EP Section) and will "auto" (: find all the methods.

    Since the following explanation, might be a little "over the head", I will be happy to interpret any hard points..


    In any case, I do not accept your first asseveration, about you did mention the same recommendation.

    respectfully,
    Elad.
  • BitByBit_ThorBitByBit_Thor Member Posts: 2,444
    : That is Correct. I do suggest a Com+ rather then API declaration,
    : since most of the time using this regimen demand the dll to be
    : pre-registered anyway, such as OCXs and DLLs in the /System32
    : Folder.

    The point is that you don't have a choice in what type of dll you are creating in VB. If you want to export functionality through VB, the only choice you have is to use COM.
    Of course you could create the dll in C++ and then use it in VB, but that's not what we're talking about here.

    : Notice that regarding external Lib. files (any) IN VB6 (!)-
    : this declaration is obsolete since the allocation of VBO Lib. does
    : not always finds the Entry Point in Exported functions, Problem that
    : does not exist in COM type libraries, which has the default File
    : Offset in Win32 SubSystem, that WILL scan Entry Point (+File
    : Offset..until the EP Section) and will "auto" (: find all the
    : methods.

    Not sure I understand what you mean by the first part here.

    :
    : Since the following explanation, might be a little "over the head",
    : I will be happy to interpret any hard points..
    :
    :
    : In any case, I do not accept your first asseveration, about you did
    : mention the same recommendation.
    :

    It's quite the same, really. Your wording in blue, and mine in green. You'll notice that, whereas I was definitely more succinct in my description, we suggest the same.

    [color=Blue]:
    : how to fix your dll:
    : (how to build a proper vb6 dll).
    :
    [/color]

    [color=Green]: In VB it's only possible to write COM DLL's, which means that you
    : always need to work with classes.[/color]

    [color=Blue]:
    : finish your stuff making sure you have made the function/sub needed
    : to be used as PUBLIC (!)
    :
    [/color]

    [color=Green]: What you want to do is add a Class, call it something like Globals,
    : and set it's Instancing to Global Multi-use.
    [/color]

    [color=Blue]:
    : add reference->browse your dll->press ok.
    :
    : in your project (say your class inside the dll called myclass1),
    : write anywhere:
    :
    : dim mc as myclass1
    : set mc = New myclass1
    :
    : you can use it like this:
    : mc.funcABC "hello"
    : [/color]


    [color=Green]: Then add a reference to the DLL in your other project and then you
    : can use your function Test without having to use Declare.[/color]

    What I see here is that we pretty much say the same thing, less the part about cmd/regsvr32, and considering the fact that I was sketching the general picture where you went into detail.

    Best Regards,
    Richard

    The way I see it... Well, it's all pretty blurry
Sign In or Register to comment.