Ray K did respond but as I said i had previous commitments for the lab
for Sept so I am just now getting back to this issue.
>
> Does Quattro Pro have a different way of loading DLLs
> in Windows 2000? Is it possible that a Quattro Pro
> update or Windows 2000 service pack might eliminate
> the issue?
No, QP loads my add-inn DLLs using the macro command {DLL.Load
MyAddin.DLL}. What QP does after this macro command i have no way of
knowing. I have installed the latest service pack for QP. My version
of Win2K is SP3 and i have regularly done the Windows Update feature.
>
> Here's an idea. Did you package an older version of
> the gpib-32.dll in your application? Is it possible
> you have multiple versions of the DLL on the machine
> in different locations? I believe Windows will search
> for a DLL in the application directory before it goes
> to the Windows system directories.
Here is where my lack of programming knowledge shows. My C++ projects
are linked using the Borland language interface file that shipped with
the GPIB driver. It is something like borlandc_gpib-32.obj and the
appropriate .H file is used after an #include statement in each module
containing a GPIB function call. I did not specifically 'package' a
GPIB-32.DLL in the project. At least until now, if I put the #include
for the .h file in each module and also link in the right .OBJ file,
then my add-in DLLs have always worked fine, at least through previous
versions of Windows (98, 95 and 3.x) and previous versions of Quattro
Pro (5, 6, 7 & 8). I would appreciate your insight/experience here. It
could well be that I have gotten these things to work so far due to some
quirk rather than accepted programming methods.
>
> Alternatively, are you specifying a path to find the
> DLL? If you were using the Windows directory for Win
> 98, it would be Windows >> System, but for Windows
> 2000, it is Winnt >> System32. I believe if the DLL
> is not found in the path, loading it fails.
If i understand correctly, this applies to direct entry programming
methods which I do not use.
>
> Another idea regards using private assemblies or
> private DLLs. I read on another discussion forum that
> this is a private copy of the DLL that your
> application uses, while other applications use the
> system DLL. I believe you have to register this DLL
> yourself.
Please explain how? Is this a 1 time thing for the installation of the
GPIB driver or is it done each time the PC boots or is it each time the
DLL is loaded? I do not know what "register this DLL" means.
>
> I found the discussion info about private assemblies
> when searching Google for "view dll loaded in
> memory". I found a utility that perhaps you can run
> while running your application. Then, when you
> compare that to running MAX, you may discover
> something. Note that I have not tested these DLL
> utilities myself, so I can't really tell you to use
> them, but I thought I'd pass along the idea.
I used one of the utilities mentioned and made the following
observations. On the Win2k PC, after QP loads the DLL containing the
GPIB calls, then there are 2 DLLs in memory; GPIB-32.dll and
GPIB-VDD.dll. At this point, my GPIB function calls return errors.
When I load N.I. MAX and scan for instruments, then GPIBN32.dll is
loaded into memory. I can now run the functions in my QP add-in DLLs.
On a Win98 PC, the following GPIB DLLs are loaded when QP loads my
add-in DLL into memory, GPIBMNGR.dll, GPIB-32.dll and NISPYLOG.dll. As
mentioned earlier, when using Win98 these QP add-in DLL functions
perform as expected without using MAX and scanning for instruments.
