Prev: Getting text from hidden text producing error
Next: Installing VB6 on Win7 64 bit
From: David Youngblood on 18 Jul 2010 21:13
"BeeJ" <nospam(a)live.com> wrote in message
news:uE0utJtJLHA.4120(a)TK2MSFTNGP02.phx.gbl...
> 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.

This document desrcibes the searh order and how to specify the location of a
dll.

http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

David


From: Viken Cerpovna on 18 Jul 2010 21:49
"Kevin Provance" <k(a)p.c> wrote in message
news:i208r1$2e2$1(a)news.eternal-september.org...
> 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>

I hope that wasn't too painful, actually offering some useful advice. There
may be hope for you yet. <bg>

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

And then again, maybe not.

Of course it probably wouldn't be wise attack my advice when others
providing supporting documentation. <g>

Viken


From: BeeJ on 19 Jul 2010 02:10
ralph formulated on Sunday :
> 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.

No I am not using LoadLibrary.

Where can I find the differences?
Does an attempt to register this .DLL create problems.
This is the message I get.
[Window Title]
RegSvr32

[Content]
The module "C:\! VB Apps\ST vX96\K8055 USB\K8055D.dll" was loaded but
the entry-point DllRegisterServer was not found.

Make sure that "C:\! VB Apps\ST vX96\K8055 USB\K8055D.dll" is a valid
DLL or OCX file and then try again.


From: BeeJ on 19 Jul 2010 02:15
Thanks. Good reference.


From: Leo on 19 Jul 2010 02:40
BeeJ formulated the question :
> ralph formulated on Sunday :
>> 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.
>
> No I am not using LoadLibrary.
>
> Where can I find the differences?
> Does an attempt to register this .DLL create problems.
> This is the message I get.
> [Window Title]
> RegSvr32
>
> [Content]
> The module "C:\! VB Apps\ST vX96\K8055 USB\K8055D.dll" was loaded but the
> entry-point DllRegisterServer was not found.
>
> Make sure that "C:\! VB Apps\ST vX96\K8055 USB\K8055D.dll" is a valid DLL or
> OCX file and then try again.

There are three types of DLLs, Standard (The Windows API and Your DLL
are of this type) T=they do not need to be registered, COM (They
usually need to be registered with regsvr32) and .Not (They need to be
registered with another utility that we aren't interested in).

--
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org


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