(Mike Mitchell)
11/6/2011 7:46:00 AM
On Sat, 05 Nov 2011 13:42:29 -0500, ralph <nt_consulting64@yahoo.net>
wrote:
>On Sat, 05 Nov 2011 16:14:22 +0000, MM <kylix_is@yahoo.co.uk> wrote:
>
>>I'm experimenting with "TyDecoder Library Example for Visual Basic 6"
>>by eSite Media, Inc to decode yEnc-encoded files.
>>
>>I get a run-time error 53 "File not found: yDecLib.dll" when the app
>>is run for the SECOND and subsequent times in the IDE.
>>
>>There's this public declaration in a .bas module:
>>Public Declare Sub ydec_set_callback Lib "yDecLib.dll" (ByVal
>>CallbackFunc As Long)
>>
>>The main form's Form_Load event:
>>Private Sub Form_Load()
>> ' setup our callback function to handle decoder events
>> Call ydec_set_callback(AddressOf yDecEventHandler)
>>End Sub
>>
>>The first time the app is run in the IDE, there's no problem.
>>
>>The SECOND and subsequent times I get error 53 on that line
>>
>> Call ydec_set_callback(AddressOf yDecEventHandler)
>>
>> "File not found: yDecLib.dll"
>>
>>I have to unload the project, then reload it, then the dll is found
>>again. The dll is in the application folder. It's not a registerable
>>dll.
>>
>>If I compile the app, there's no problem. It works every time the app
>>is run.
>>
>
>This is a common problem with 'regular' API DLLs (non-ActiveX DLLs).
>The exact chain of events which leads to the problem varies depending
>on the VB Project, how it is being launched, and what it might be
>doing while it is running, thus the simplest 'cure' will be equally
>dependent on YOUR problem domain.
>
>The problem stems from two basic issues:
>
>1) This Declaration:
>
>>Public Declare Sub ydec_set_callback Lib "yDecLib.dll" (ByVal
>>CallbackFunc As Long)
>>
>Note there is no path provided. Whenever this call is made - VB is
>going to check in the current directory then follow the usual default
>of looking in \System, \Windows, etc.
>
>2) The VBIDE adds hidden code to test any call it makes using a
>Declare statement. It does not "load" the DLL once (as in the case of
>an executable), but will actually attempt to resolve the "declared
>lib" every time the call is made.
>
>Multiple 'fixes' are available:
>
>1) Set up a unique location for the DLL during development and provide
>a full path for the Declare Statement.
>Obviously a hard-coded folder would be a pain for the finished
>product, so you might include a compile time conditional - use the
>Declare with a relative path for production, hard-coded one for
>development.
>
>2) Make sure while developing in the VBIDE that its concept of the
>"current directory" is always returned to where the DLL is physically
>located before making any call.
>
>3) Place the DLL in a 'windows' default folder - the System folder for
>example. Note, you only have to place the DLL there for the
>development box. The Executable would still work with the DLL in the
>App path as before.
>
>...
>
>HTH
>-ralph
Whew! Well, whaddya know! That was a very clear explanation of how it
happens, I never knew.
What I finally decided to do after posting the original message was to
comment out the dll in the app folder and copy the dll to \system32.
Because the final app will run reg-free, with the dll in the app
folder or possibly the \Deps folder.
Strange that I've not noticed this before in over a decade of VB6
coding!
MM