Sorry...cannot find the DynaPDF.dll file

[MLH]

Am using StrStorage.dll & DynaPDF.dll
(Lebans tools) for creating PDF's. At most
sites, there are no glitches. However, I
have a problem at one site.

Just so happens its a site on which I mentioned
in another thread that, in spite of my having installed
a runtime application there, I'm apparently not
operating in a runtime environment, as the database
window will display with the right commands.

The Sorry...cannot find the DynaPDF.dll file message
I keep getting is in spite of the fact that the file
exists both in the system32 directory and the
app dir. Anyone set me straight on this?

[Stephen Lebans]

The DLL should reside in the same folder as the Front End of your app. If
you look through the code you will see it checks the current folder to see
if the DynaPDF DLL exists and if so calls LoadLibrary against it.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"MLH" <CR**@NorthState.netwrote in message
news:1f********************************@4ax.com...

Am using StrStorage.dll & DynaPDF.dll
(Lebans tools) for creating PDF's. At most
sites, there are no glitches. However, I
have a problem at one site.

Just so happens its a site on which I mentioned
in another thread that, in spite of my having installed
a runtime application there, I'm apparently not
operating in a runtime environment, as the database
window will display with the right commands.

The Sorry...cannot find the DynaPDF.dll file message
I keep getting is in spite of the fact that the file
exists both in the system32 directory and the
app dir. Anyone set me straight on this?

[MLH]

I remember that part. And for all but one of the folks I've
recommended this to, it seems to follow exactly what you
said. But for one guy, he has it in the AppDir and even in
System32 - which, of course, is in the PATH. Still, the error
persists. So I'm thinking there might be something unusual
about his system causing this. Dunno.
On Fri, 17 Nov 2006 12:26:40 GMT, "Stephen Lebans"
<[e-mail]:

>The DLL should reside in the same folder as the Front End of your app. If
you look through the code you will see it checks the current folder to see
if the DynaPDF DLL exists and if so calls LoadLibrary against it.

[Tom van Stiphout]

On Fri, 17 Nov 2006 08:35:51 -0500, MLH <CR**@NorthState.netwrote:

So why don't you enhanve the error message to tell you where it looked
for the DLL, and where the AppDir is?

-Tom.

>I remember that part. And for all but one of the folks I've
recommended this to, it seems to follow exactly what you
said. But for one guy, he has it in the AppDir and even in
System32 - which, of course, is in the PATH. Still, the error
persists. So I'm thinking there might be something unusual
about his system causing this. Dunno.
On Fri, 17 Nov 2006 12:26:40 GMT, "Stephen Lebans"
<[e-mail]:

>>The DLL should reside in the same folder as the Front End of your app. If
you look through the code you will see it checks the current folder to see
if the DynaPDF DLL exists and if so calls LoadLibrary against it.

[Tom van Stiphout]

On Fri, 17 Nov 2006 12:26:40 GMT, "Stephen Lebans"
<[e-mail]:

Stephen,
I haven't seen the code for DynaPDF, but why are you checking if it
exists, rather than allowing Windows to do what LoadLibrary normally
does, which includes checking for the DLL in various locations
(AppDir, CurDir, SystemDir, etc) in a defined order? Some might say:
so I can control which version is used. But then I say: not if you're
the second app and another copy of the library is already in memory.

If the OP wants that behaviour, he could just comment out the check
for existence, and the path part of the filename passed into
LoadLibrary.

-Tom.

>The DLL should reside in the same folder as the Front End of your app. If
you look through the code you will see it checks the current folder to see
if the DynaPDF DLL exists and if so calls LoadLibrary against it.

[Stephen Lebans]

Hi Tom,
two reasons:

1) I would prefer the DLL be placed in the same folder as the front end
MDB/MDE. For XP and later, MS strongly suggest this course of action.

2) The behaviour of which and what order WIndows searches is different
across all of the windows versions.

For the last several months, I have been receiving on average, 3 - 5 EMail
requests a day for help with my ReportToPDF solution. In 90% of the cases,
users do not follow my instructions for locating the DyanPDF DLL.

I'm just trying to reduce Tech support requests.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Tom van Stiphout" <no*************@cox.netwrote in message
news:ch********************************@4ax.com...

On Fri, 17 Nov 2006 12:26:40 GMT, "Stephen Lebans"
<[e-mail]:

Stephen,
I haven't seen the code for DynaPDF, but why are you checking if it
exists, rather than allowing Windows to do what LoadLibrary normally
does, which includes checking for the DLL in various locations
(AppDir, CurDir, SystemDir, etc) in a defined order? Some might say:
so I can control which version is used. But then I say: not if you're
the second app and another copy of the library is already in memory.

If the OP wants that behaviour, he could just comment out the check
for existence, and the path part of the filename passed into
LoadLibrary.

-Tom.

>>The DLL should reside in the same folder as the Front End of your app. If
you look through the code you will see it checks the current folder to see
if the DynaPDF DLL exists and if so calls LoadLibrary against it.

[MLH]

Makes sense to me, your objective. In my case, I have
it in two places ==didn't really expect that to remedy
the issue. But hey, one never can tell.

Could it be that my runtime installation there is complicated
by the fact that the user also runs retail version of A97 on
his machine? I even tried putting the dll in c:\program files\
Microsoft Office\ there with the msAccess.exe file. Didn't
help me.