From: BeeJ on
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.


From: Viken Cerpovna on
"BeeJ" <nospam(a)nowhere.com> wrote in message
news:i200q7$eg$1(a)speranza.aioe.org...
> 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.


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

From: BeeJ on
Viken Cerpovna wrote on 7/18/2010 :
> "BeeJ" <nospam(a)nowhere.com> wrote in message
> news:i200q7$eg$1(a)speranza.aioe.org...
>> 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.
>
>
> 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

Windows XP.
One is in C:\Windows\System32
One is in Q:\Apps\DLLS
So maybe your hint is to fully qualify the path in the declaration.
I can set up the install to put them under the App Exe and declare the
path there.
I do not believe the environment has any paths referenced.
I have forgotten how to look at the environment.


From: ralph on
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 ?

The program will "use" the first DLL it finds to complete to launch
process, however if there are other instances already loaded the VMM
will likely perform a few "short-cuts" as to insure it is "shared" -
but is seldom a concern.

>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.
>

There are many differences, but in this case ...

If you do not specify a path for libname (Lib), Visual Basic will
search for the file in the following order:
1) Folder containing the .exe file
2) Current folder
3) Windows system directory
(but not necessarily \Windows\System or \winnt\System32, on some corp
exotic configurations.)
4) The Windows directory
5) Paths found in the Path environment variable

If not found in those locations the Program will not load and will
give an error when launched. But you never mention an Error. You just
say it doesn't work or doesn't return the correct result. This leads
me to believe that location isn't your problem.

[Ignoring for the moment the chance you are calling LoadLibrary and
swallowing the error. Are you using LoadLibrary?]

>Can someone explain or give me a link for this specific situation.
>
From: Kevin Provance on

"BeeJ" <nospam(a)live.com> wrote in message
news:uE0utJtJLHA.4120(a)TK2MSFTNGP02.phx.gbl...
:
: Windows XP.
: One is in C:\Windows\System32
: One is in Q:\Apps\DLLS
: So maybe your hint is to fully qualify the path in the declaration.
: I can set up the install to put them under the App Exe and declare the
: path there.
: I do not believe the environment has any paths referenced.
: I have forgotten how to look at the environment.

No, you don't want to fully qualify the path in your declare. Never, ever,
hard code paths. Ever. Not for production code. If you want do to it for
debugging purposes, then that's something else. You might try it then...but
remember to fix it when distributing, otherwise you'll be in support hell.
<g>

FWIW, you are taking advice from some sad little boy whose name is an
anagram of mine and has made very clear why he's suddenly showed up in our
community, and it's not to help with VB.