-
May 26th, 2019, 10:42 PM
#1
Thread Starter
Frenzied Member
Is there a maximum DLL path length for Delcare statement?
I'm loading a DLL function in VB6 using the Declare statement. And I know the file is at this path, but VB6 says the DLL file isn't found.
Code:
Private Declare Function TccNew Lib "C:\Users\MY_NAME\Desktop\tcc\tcc-0.9.27-dev\libtccwrapper.dll" () As Long
It's a fairly long path, but it's a legit actual path. Is there some maximum length for the path to a DLL file for a DLL function declared with the Declare statement?
-
May 26th, 2019, 11:34 PM
#2
Re: Is there a maximum DLL path length for Delcare statement?
I am not sure about VB6 back in VB5 I ran into a limit, seems like it was 50 characters max, since then I have avoided the really long path names just in case.
-
May 27th, 2019, 02:41 AM
#3
Lively Member
Re: Is there a maximum DLL path length for Delcare statement?
Have you tried copying the library to somewhere else with a shorter path name? If it works this would eliminate other possible causes.
-
May 27th, 2019, 02:47 AM
#4
Re: Is there a maximum DLL path length for Delcare statement?
Using this kind of path with a username in it is only going to work on a single specific computer.
On all or computers it will fail because of a different user name.
-
May 27th, 2019, 09:46 AM
#5
Re: Is there a maximum DLL path length for Delcare statement?
The easiest advice is: Put a copy of your flat DLL next to the EXE and reference it by its simple name, not full path.
Normally manifests are used to provide paths to non-system flat DLLs these days. That's not viable for IDE testing though, so on a development system you'd normally do something else such as add an entry to the PATH environment variable but don't do this on end user machines.
There are other scenarios but they can be more complicated. Consider that the system drive might not even be the C: drive on many machines.
Also see Search Order for Desktop Applications.
VB can be easy to use, as long as you stick to the easy things it supports for new users. But development and deployment are two separate and deep topics. That's part of why Microsoft ran to .Net and ClickOnce and are now following the rest of the world to bottom-tier scripting languages like Python and JavaScript: supporting opportunistic developers was getting too costly.
Mort, Elvis, Einstein, and You
We're all a mix of the three.
-
May 27th, 2019, 12:14 PM
#6
Re: Is there a maximum DLL path length for Delcare statement?
Originally Posted by dilettante
The easiest advice is: Put a copy of your flat DLL next to the EXE and reference it by its simple name, not full path.
Another way would be to leave the DLL where it is, reference (Declare) it without path and do a LoadLibrary() with the full path at startup. After that LoadLibrary call, once a Sub or Function in this DLL has been called, the handle can be freed (FreeLibrary()) since the DLL is now loaded into the process space.
Wolfgang
-
May 28th, 2019, 06:29 AM
#7
Re: Is there a maximum DLL path length for Delcare statement?
Originally Posted by Wolfgang Enzinger
Another way would be to leave the DLL where it is, reference (Declare) it without path and do a LoadLibrary() with the full path at startup.
Best approach IMO.
Leave the declares "bare" like Declare Function TccNew Lib "libtccwrapper" () As Long i.e. no path, no .dll suffix and lower-case filename only (like "user32" etc.)
Then upon InIde you can hard-code exact file+path on your dev machine in single LoadLibrary "C:\Users\MY_NAME\Desktop\tcc\tcc-0.9.27-dev\libtccwrapper.dll" call.
For release build just place the .dll next to your executable so that the declares can find it or you can once again re-route the .dll w/ a LoadLibrary from a specific sub-folder for instance.
cheers,
</wqw>
-
May 28th, 2019, 02:15 PM
#8
Re: Is there a maximum DLL path length for Delcare statement?
Originally Posted by wqweto
...or you can once again re-route the .dll w/ a LoadLibrary from a specific sub-folder for instance.
That's what I do (usually via a SubFolder named \Bin\ - below the App-Path) ...
Then it becomes unnecessary, to make any distinctions between IDE-Mode and Exe-Mode...
The LoadLibrary-call is then always active in both modes as:
LoadLibrary App.Path & "\Bin\TheExternalLib.dll"
App.Path will resolve to the path of the *.vbp in IDE-Mode - and to the Path of the Binary when it runs compiled.
For ActiveX-Dll-Projects, which wrap such Flat-Libs, I remove the \Bin from the LoadLibrary-call (so that they'll look-up their flat-Dlls "beside themselves").
Olaf
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|