Prev: Getting text from hidden text producing error
Next: Installing VB6 on Win7 64 bit
From: Paul Clement on 19 Jul 2010 07:58
On Sun, 18 Jul 2010 18:11:49 -0500, "Viken Cerpovna" <viken(a)spam.com> wrote:


� > This manufacturer's M.DLL is the non-register type.
� > So how do I know
� > 1) which M.DLL it is talking to if there happens to be multiple of the
� > same M.DLL in several folders. The declaration does not say. It just
� > says the M.DLL with no path name. Is that expected to only reside in
� > Windows\SYSTEM32 ?
� > e.g.
� > Private Declare Function OpenDevice Lib "k8055d.dll" (ByVal CardAddress As
� > Long) As Long
� >
� > 2) how is a registered vs non-registered M.DLL different except for a
� > reference in the registry. There must be other differences.
� >
� > Can someone explain or give me a link for this specific situation.
�
�
� Depends upon a number of factors, but for the most part it's going to depend
� upon the Windows search path when attempting to locate DLLs with a non
� qualified path and whether it's currently loaded in memory. It would
� probably help to know which version of Windows you are using and whether
� k8055d.dll is installed in multiple locations and what those are.
�
� Viken

Don't think that memory matters in the 32-bit world. That is, unless you're referring to the
application process space.

Back in the 16-bit world the memory would be checked first before executing the DLL search order.
There was also a Known16DLLs Registry entry that could override the search order.


Paul
~~~~
Microsoft MVP (Visual Basic)
From: Paul Clement on 19 Jul 2010 08:04
On Sun, 18 Jul 2010 15:56:07 -0700, BeeJ <nospam(a)nowhere.com> wrote:

� Still pondering why my ActiveX EXE is not working.
� My ActiveX EXE talks to a manufacturer's M.DLL that does not return the
� correct result when the ActiveX EXE is referenced/used as a .EXE but
� does return the correct result when the ActiveX EXE is
� referenced/running in the IDE.
�
� This manufacturer's M.DLL is the non-register type.
� So how do I know
� 1) which M.DLL it is talking to if there happens to be multiple of the
� same M.DLL in several folders. The declaration does not say. It just
� says the M.DLL with no path name. Is that expected to only reside in
� Windows\SYSTEM32 ?
� e.g.
� Private Declare Function OpenDevice Lib "k8055d.dll" (ByVal CardAddress
� As Long) As Long
�
� 2) how is a registered vs non-registered M.DLL different except for a
� reference in the registry. There must be other differences.
�
� Can someone explain or give me a link for this specific situation.
�

The following should help:

INFO: Windows NT/2000/XP Uses KnownDLLs Registry Entry to Find DLLs
http://support.microsoft.com/kb/164501

Also, I would recommend using the Process Explorer utility to identify which DLLs are being loaded
by your application:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Paul
~~~~
Microsoft MVP (Visual Basic)
From: Viken Cerpovna on 19 Jul 2010 19:50
"Paul Clement" <UseAdddressAtEndofMessage(a)swspectrum.com> wrote in message
news:6qe846ld705omj1q0sg1pb0r0l8koktub3(a)4ax.com...
> On Sun, 18 Jul 2010 18:11:49 -0500, "Viken Cerpovna" <viken(a)spam.com>
> wrote:
> � Depends upon a number of factors, but for the most part it's going to
> depend
> � upon the Windows search path when attempting to locate DLLs with a non
> � qualified path and whether it's currently loaded in memory. It would
> � probably help to know which version of Windows you are using and whether
> � k8055d.dll is installed in multiple locations and what those are.
> �
> � Viken
>
> Don't think that memory matters in the 32-bit world. That is, unless
> you're referring to the
> application process space.
>

Yes, that is what I meant. Thanks.

Viken

From: BeeJ on 19 Jul 2010 21:02
Eureka!

Thanks all for you input.

It is now solved.
Here is what happened.
The manufacture supplies two .DLLs, one old (that works with my USB
interface) and one new (that does not work with my interface).
(the manufacture support folks tell me there is only one version of the
module but the documentation tells me there are actually three
revisions to the hardware and the latest hardware rev is needed for the
new .DLL). Some support! All that added to my confusion.

Both DLLs are unfortunately named the same by the manufacturer.
One was located in System32, the old .DLL.
One was located in the app main folder, the new .DLL.
So when running in the IDE, the old .DLL was being used since the
ActiveX EXE source is in a subfolder of the main app.
When running the compiled app, the new .DLL was being used.
So I have adjusted the names and locations so this cannot easily happen
again.
And, I will be checking the version of the DLL in my main app to make
sure the correct one has been installed or being accessed, just in case
a user decides to play around.

P.S. love MesNews. great spell checker too.
Fast and responsive.


First  |  Prev  | 
Pages: 1 2 3
Prev: Getting text from hidden text producing error
Next: Installing VB6 on Win7 64 bit