Results 1 to 5 of 5
  1. #1
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Building a DLL with VB6 (VB6/ Office 2000)

    I'm experimenting with providing an Excel (VBA-referenced) add-in as a DLL built in VB6. I have two versions of the same thing I'm playing with:

    V1 - Built as a standard Windows DLL, containing a Public Function DllMain and defined entry points.
    V2 - Same functions encapsulated in a class module.

    V1 functions can be called from a standard EXE, but none of these functions appear in the XL VBA object browser.
    V2 won't work as a standard Windows DLL (called from an EXE) but does expose its public class member functions to the VBA editor. However, any functions outside the class module are not exposed.

    Since I'm only tinkering, not having built a DLL for an Office app before, could someone offer some tips on the best way to structure things. In particular, does everything need to be in Class modules?

    BTW, running from an EXE is not a requirement - I was just using that scenario as a familiar testing ground.

    thanks

  2. #2
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Building a DLL with VB6 (VB6/ Office 2000)

    <P ID="edit" class=small>(Edited by AlanMiller on 11-Aug-05 22:28. )</P>I think this situation I described might sound a bit obscure, so I'll answer my own post in part. I've been able to build both ActiveX and standard Windows DLLs from VB6, to do the same things. I can now access both/ either from Excel VBA. The thing I couldn't grasp is that when a DLL is Referenced in the VBA project, all the member functions defined within class modules become available, as shown in the Object Browser. However, functions defined outside of a class must be declared explicitly in the VBA project, using the DLL name as the libname parameter in a Declare statement.

    For the test case I'm using, I have to include the full DLL path in these declarations, even though the DLL is (self-) registered. I foresee the problem of end-users having different paths to this DLL, so is there a way around this, other than putting the DLL in the WindowsSystem folder etc.?

    Alan

    The closest I've come to an answer so far is trying to use something like:
    <code>
    Public Declare Function Increment Lib ThisWorkbook.VBProject.References("MyLibABC").Full Path (var As Integer) As Integer
    </code>
    in place of the "standard" declaration of the form:
    <code>
    Public Declare Function Increment Lib "C: ... MyLibsMyLibABC.dll" (var As Integer) As Integer
    </code>
    VBA only wants to entertain a string constant for the libname though.

  3. #3
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: Building a DLL with VB6 (VB6/ Office 2000)

    What if you add your folder to:

    HKEY_CURRENT_USEREnvironment ===> Path

    (Perhaps there is an API call to do this?)

  4. #4
    Platinum Lounger
    Join Date
    Nov 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    5,016
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Building a DLL with VB6 (VB6/ Office 2000)

    Thanks for that thought Jefferson. I've been toying with that, and other methods, but have decided that I'm trying to get chalk to mix smoothly with cheese... from two different technology eras almost. I will probably go with 2 versions of the same DLL for the different end uses. I did, however, give thought to an INI file for general user-specific settings.

    Although it won't overcome the "string constant" requirement for the API-style Declarations, it may prove just the thing for other info. I guess the way to use one would be to read all appropriate entries on Open event. I know you like using these - do you favour accessing them through the API or using WSH?

    Alan

  5. #5
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: Building a DLL with VB6 (VB6/ Office 2000)

    To read a well-formatted INI file in Word, you can use GetPrivateProfileString. More ad hoc files can be read either with the crusty old VB file access commands or with the FileSystemObject. I find the FSO much easier to program, as the syntax is like the rest of VBA. But there is speed penalty, if speed is important...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •