Prev: Passing object across processes
Next: VB(A) library of Bessel functions
From: ImageAnalyst on 7 Jan 2010 11:37
Hard coding the full paths into the Declare statement didn't work.
From: ImageAnalyst on 7 Jan 2010 11:59
Well I did get it to work (but not in the way I had hoped).
I had to put the pgOverlay.dll file in the folder where the ActiveX
DLL's that it calls live. And I had to hard code the path to that
folder into the declare statement even though that folder was on the
PATH envinronment variable. I guess I can live with putting the
pgOverlay.dll into that folder but I hoping to not have the folder
hard coded into the declare statement. But if I take out that path I
get the same error about it not finding the DLL. Any explanation for
that, or how I can remove the hard coded path (since I'm not sure my
end users installed the Aphelion ActiveX DLL's in the same folder name
that I did)?
Thanks,
ImageAnalyst


What I have so far:

'--------------------------------------------------------------------------------------------------------------
' Declare the pgOverlay functions that are contained in the
pgOverlay.DLL file.
' It seems that if the pgOverlay file does not reside in the same
folder as the
' Aphelion ActiveX DLL's, then it can't find pgOverlay.DLL,
' even if pgOverlay.DLL is in one of the folders on the normal search
order (folders that Windows looks in to find it).
' If pgOverlay is not in the Aphelion/Program folder, then even hard
coding the full path to pgOverlay.DLL won't help it work
' Note: "C:\PROGRA~1\Aphelion\Program" is in the PATH Environment
variable.

' This DOES NOT work, even if pgOverlay.dll is in the Aphelion\Program
folder which is in the PATH Environment Variable
' and where the Aphelion ActiveX DLLs are.
Declare Function pgovlCloseOverlayFile Lib "pgOverlay.dll" (ByVal
lngFilePointer As Long) As Long
Declare Function pgovlCreateOverlayFile Lib "pgOverlay.dll" (ByVal
sFilename As String) As Long

' This DOES work, as long as pgOverlay resides in the folder "c:
\program files\Aphelion\Program"
' which is where the Aphelion ActiveX DLL's live.
'Declare Function pgovlCloseOverlayFile Lib "c:\program files\Aphelion
\Program\pgOverlay.dll" (ByVal lngFilePointer As Long) As Long
'Declare Function pgovlCreateOverlayFile Lib "c:\program files\Aphelion
\Program\pgOverlay.dll" (ByVal sFilename As String) As Long
From: Ralph on 7 Jan 2010 13:47
ImageAnalyst wrote:
> Well I did get it to work (but not in the way I had hoped).
> I had to put the pgOverlay.dll file in the folder where the ActiveX
> DLL's that it calls live. And I had to hard code the path to that
> folder into the declare statement even though that folder was on the
> PATH envinronment variable. I guess I can live with putting the
> pgOverlay.dll into that folder but I hoping to not have the folder
> hard coded into the declare statement. But if I take out that path I
> get the same error about it not finding the DLL. Any explanation for
> that, or how I can remove the hard coded path (since I'm not sure my
> end users installed the Aphelion ActiveX DLL's in the same folder name
> that I did)?
> Thanks,
> ImageAnalyst
>
>
> What I have so far:
>

Which I'm glad to see. Just wrote a wordy reply that contained mostly items
which we can now eliminate. <g>

Found a reference to this being a problem if the system %PATH% variable is
too long, however, it appears to be O/S specfic and repaired. For grins why
not move the Aphelian folder up close to the front of the PATH EnvVar
string.

Make sure you have only one copy of "pgOverlay.dll" on the box. Temporarily
rename the others, as the search routine will bail on the first one if
finds. It appears that it is not actually "pgOverlay.dll" that is the
problem, but finding the components it depends on after you find it.

Warning Exotic Possiblity and Air Code follow... <g>

Since Vista, various security changes in the O/S, (and new C++ compiler
options are availble) to prevent a DLL being called outside of certain
contexts.
What other environments or applications is this DLL used for?
For grins create a simple VB Exe and use the WinAPI to test.

Private Declare Function GetModuleHandle Lib "kernel32" Alias
"GetModuleHandleA" _
(ByVal lpModuleName As String) As Long
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" _
(ByVal lpLibFileName As String) As Long
Private Declare Function GetProcAddress Lib "kernel32" _
(ByValhModule As Long, ByVal lpProcName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" _
(ByVal hLibModule As Long) As Long

Public Function IsExported(ByVal ModuleName As _String, _
ByVal ProcName As String) As Boolean
Dim hModule As Long
Dim lpProc As Long
Dim FreeLib As Boolean
' check to see if module is already loaded
hModule = GetModuleHandle(ModuleName)
If hModule = 0 Then
hModule = LoadLibrary(ModuleName)
FreeLib = True
End If
' check to verify it's exported.
If hModule Then
lpProc = GetProcAddress(hModule, ProcName)
Exported = (lpProc <> 0)
End If
' unload library if we loaded it here.
If FreeLib Then Call FreeLibrary(hModule)
End Function

This will use the LoadLibrary process directly thus generally removing any
subtle nuances the VB Declare Function statement might have on a new O/S.
Plus if you cannot get around using a fullpath with the VB statement, this
process will allow you to access the library/functions building a dynamic
path at runtime. It will be easier if you also create a typelib for the Dll.

-ralph






From: ImageAnalyst on 7 Jan 2010 15:41
Ralph:
Thanks for much for your help. It's working now. I still had a
version of the pgOverlay.dll in the Windows folder and when I didn't
have the full name in the "Declare" statement it apparently was using
that instead of the version in the Aphelion\program folder (because
Windows is earlier in the PATH environment variable and search
order). Now, I know from before (thankfully due to your hint) that my
VB6 app must use the pgOverlay.dll in the Aphelion/program folder
because that is where the dependent activeX DLLs live. So once I got
rid of the version in the Windows folder (which is earlier in the path
than the Aphelion\program folder) then it was now using the proper DLL
in the proper location (the Aphelion/program folder) and it all worked
fine.

I'm still not exactly sure why my DLL had to live where the dependent
ActiveX DLL's live (because those DLLs' folder was on the path), but
hey, as long as it's working...

Thanks again for taking the time to help me with this!



P.S. The path was very lengthy - maybe around 400 characters or more:
C:\Program Files\Notes5;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%
\System32\Wbem;%SystemRoot%\system32\nls;%SystemRoot%\system32\nls
\ENGLISH;c:\program files\ixos\ixos ecd viewer\bin;C:\Program Files
\Hewlett-Packard\OpenView\service desk 4.5\client\bin;C:\Program Files
\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2010a\runtime
\win32;C:\Program Files\MATLAB\R2010a\bin;C:\Program Files\MATLAB
\R2009b\bin;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files
\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\90\Tools\binn
\;C:\Program Files\QuickTime\QTSystem\;C:\PROGRA~1\Aphelion\Program
I guess it needs cleaning - I don't even use Notes anymore for email -
it's been uninstalled! I'm using Windows XP. Is there are limit to
the length of the PATH environment variable in WinXP?
First  |  Prev  | 
Pages: 1 2
Prev: Passing object across processes
Next: VB(A) library of Bessel functions