API - Dynamic Load External References 2

[Florent]

Good Morning ;

In my macros, I'm using some home-made DLL.
I want that my macros aren't saved with fixed path on used DLL. Because, this macro are duplicated on different sites, and I want to manage them simply (eg : update by replace the swp file).

I tried to add this code :

    Application.VBE.VBprojects(1).References.AddFromFile "FullPath"

But the call of a function or the use of a type contained in the external DLL, aren't accepted by compilator.

Then, I tried to add compilation instruction like "#if" but I didn't manage to find the equivalent of the Access VBA call :

    Application.VBE.VBprojects(1).SetOption "Conditional Compilation Arguments", "AcceptLibraryCode = False"
    RunCommand acCmdCompileAndSaveAllModules

to execute the instructions which were ignored during the first compilation by "#if" statment.

Many thanks for your help.

SW2007 SP5
Worksatation HP wx4300 2GB
NVidia Quadro FX 3450

 

[Florent]

Nobody has enough knowledge in VB to help me in my issue ?

I thought that I was the only-one to write macro usable in different countries and languages ...

What are your advises so ?


SW2007 SP5
Worksatation HP wx4300 2GB
NVidia Quadro FX 3450

 

[TheTick]

A good place to post for API help is on the API forum in the SW site.

I think your DLL needs to be registered on each computer and installed as a reference in the macro (under "Tools --> References")

If you're already compiling a DLL, why mot do the whole thing as an EXE or addin?

Honesty may be the best policy, but insanity is a better defense.

http://www.EsoxRepublic.com

-SolidWorks API VB programming help

 

[EEnd]

Since I have not worked with VBA and DLLs in this manner the following comments are guesses and may be completely wrong.

One of the main jobs of a compiler is checking that data types are properly used and that function calls have the correct arguments. This requires knowledge of the data types and function calls at compile time. The two approaches that you listed do provide the compiler with the needed information which leads to the compiler error.

I believe that the standard way VBA interacts with DLLs is through the references dialog, where you can check existing libraries and browse to new ones. The libraries that appear in the list are ones which have been registered with Windows. One piece of information that ends up in the Windows registry as part of the registration process is the location of the DLL. Once VBA knows the references the compiler can perform its consistency checks.

You have to browse to the DLL in the case where it is not registered with Windows, and this process creates the link between your macro and the DLL (including its path).

If you were to register your DLL with Windows then you would not have to browse to the file and there would be no hard link to the DLL.

You will have to register the DLL on all computers to which the macro is distributed, in addition to your development computer. The package that you are using to create your DLL should also generate files with the information needed to register the DLL. I have worked some with registering libraries created in .NET for use with C++ applications. The .NET compiler creates a .tlb (type library) file which is registered with a command like:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\regasm /verbose FileName.dll /tlb:FileName.tlb

Once set up this way the VBA macro should not be dependant on the location of the DLL, as the location is defined when the library is registered.

I hope the above points you to your solution.

By the way, what are you trying to accomplish that is hindered by a hard link to the location of the DLL within the VBA project?

Eric

 

[Florent]

Thanks for you two (TheTick and EEnd)

I've deployed my library on all machines and register it with
regsvr32 tool, (because my library is a VB6).

And now its works perfectly.

For you question Eric, yes I was trying to have my DLL on a local server with different access path depending on the local configuration.

Eg :
In France, I can have a a UNC path like :
serverFr\SWMacros\Libraries
And in Spain
serverSp\SWModel\Macros\FrenchMacros\Librairies

Your solution is the best. The only thing I'll have to do is update the DLL deployed on all machines when I modify it.
But it can be done with a script on a opening windows session with ActiveDirectory.

Thanks again.


SW2007 SP5
Worksatation HP wx4300 2GB
NVidia Quadro FX 3450

 

[brengine]

It involves another setup/install item, but...
You could store the variable/location path in the registry somewhere. I've done that with macros (to store user previous selections or whatever) and it's actually quite easy. You can read/write to the registry with batch files too (I think, it's been a while).

Ken