Accessing system environment variables

[Gary G. Little]

I needed to know the OS, whether 32 or 64 bit, so that I could properly set
the \Program Files path to find whatever version of Acrobat is installed.
The 64 bit OS versions use both \Program Files and \Program Files (x86), and
since Acrobat reader is only 32 bits, it installs into the (x86) path. The
problem is that the VB code shells out to the Adobe Reader via an explicit
path based on a 32 bit OS installation and hence can never find the reader
since it always looks in \Program Files and never \Program Files (x86). The
code was developed on 32 bit systems so using that explicit path was
acceptable at the time. With the advent of newer 64 bit systems that
obviously ain't gonna work for everybody.

Trying to resolve the issue with minimal impact, I added this line to the
module:

if Left(Environ("PROCESSOR_ARCHITECTURE"), 5) = "AMD64".

However ... Environ always returns "x86", the if takes the else clause and I
never find the Acrobat Reader. It does this whether I'm under XP 64 Pro on a
dual XEON system, or under Vista 64 Ultimate on a Core 2 Duo T7500. When I
enter a command line and look at the variable it shows "AMD64". It's almost
like ACCESS and VB reload the environment variable(s) because everywhere
else I look at that var it's always "AMD64" and not "x86".

I also tried the PROCESSOR_IDENTIFIER but on the XEON that is "EM64T", but
on the core 2 Duo it i s "Intel64". The solution may be to simply use
Environ("ProgramFiles(x86)").

Anyone else encountered this type of problem?

Gary

 

[Klatuu]

I really don't know how reliable Environ is anymore. If I use
?Environ("OS") it returns Windows_NT

Oh, Really?

I use the code at this site:
http://www.mvps.org/access/api/api0055.htm

?fOsName it returns Windows XP (Version 5.1) Build 2600 (Service Pack 2)

Quite a difference.
Hopefully, this will help.

 

[Albert D. Kallal]

why do you need to know the location of Adobe Reader?

To launch/view an adobe document, just go:


Application.FollowHyperLink "c:\mypdf\pdfName.pdf"

I seem quite a lot of work you are suggesting here to solve problem that
will occur OVER AND OVER EACH TIME they upgrade Adobe Reader, and the
location/directory changes.

Really, you DO NOT want to design your software with hard coded paths to
adobe...it just going to be a pure nightmare from a support point of view.

If you need to print a pdf document, just go:

CreateObject("Shell.Application").Namespace(0).ParseName("c:\mypdf\myDoc.pdf").InvokeVerb
("&Print")

It is one line of code, and if you using adobe 5, 6, 7, 8 or who knows what
version, they are all in different install locations, the above print
command will still work.

It really is a mess to try and maintain code that relies on a hard coded
path name to .exe file.

 

[Gary G. Little]

Albert,

Having been in this industy for over 30 years I absolutely agree with you:
You NEVER use a hardcoded path ... even something braindead like "C:\" can
byte you when you discover your OS was installed on E:\. However, in this
case it really really is a lot easier to simply write the code to find out
the version and location of Adobe and then launch it. The Access 2007 DB is
used to maintain contest scores for conventions that are held across the
country through out the year. The laptops being used are personally owned
and vary from the latest with Vista 64 down to, I hope, at least WinXP,
MAYBE service pack 1. Yeah, we get LOTS of complaints about speed which are
mostly met with "George, if you had updated your laptop after you had your
last great grand child, like you said you would, you might not have that
problem.". Getting EVERYONE across the country, and some foreign countries,
to actually go by a new laptop is virtually impossible since all of the
expense is out of pocket. The particular chunk of code uses "if ... elseif"
clauses to clunk through every version of Adobe back to 4.0, and across the
society, I'm sure everyone of them runs on at least one laptop.

All of that was working for everyone but me ... of course ... because my new
system is, since I'm a developer, 2 meg with Vista 64 Ultimate.

Better than Environ, is there a Do.Cmd that would acquire the OS version and
platform, whether 32 or 64?

 

[Albert D. Kallal]

Better than Environ, is there a Do.Cmd that would acquire the OS version
and
platform, whether 32 or 64?

The follwing windows api code should work:

http://vbnet.mvps.org/index.html?code/helpers/iswinversion.htm

I not tried it in ms-access, but I have lifted a fair bit of api examples
for vb6 code from the above Randy's site, and most of the time there is
little difficulty in getting the code to work in ms-access. (the forms code
stuff will be different, but the api, and rest of the code will work fine in
ms-access).

 

[Tony Toews [MVP]]

I needed to know the OS, whether 32 or 64 bit, so that I could properly set
the \Program Files path to find whatever version of Acrobat is installed.

I'm wondering if you can use an API call to determine what app is
registered to the PDF extension and work backwards from there? Of
course if the user has another reader/writer installed it won't
necessarily work.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[bennie]

GJH NMNMMJ NMNMNM.M,NMK,BLM N HGMBFMGFN BH HB NBNGVNYHDFBFB
JGBVHBFBBFHFBFBBFHBHFHB BNHFHFB HFBHHFBFNFNJFNBBFJBFBF;GGGMGNB
CNFBFHFBBFHHFBHFBGFNBHFBVHBFBFG

 

[Gary G. Little]

Thanks Tony. Indeed there is a registry entry, so I may pursue that.

Gary

 

[David W. Fenton]

Having been in this industy for over 30 years I absolutely agree
with you: You NEVER use a hardcoded path ... even something
braindead like "C:\" can byte you when you discover your OS was
installed on E:\. However, in this case it really really is a lot
easier to simply write the code to find out the version and
location of Adobe and then launch it. The Access 2007 DB is used
to maintain contest scores for conventions that are held across
the country through out the year. The laptops being used are
personally owned and vary from the latest with Vista 64 down to, I
hope, at least WinXP, MAYBE service pack 1. Yeah, we get LOTS of
complaints about speed which are mostly met with "George, if you
had updated your laptop after you had your last great grand child,
like you said you would, you might not have that problem.".
Getting EVERYONE across the country, and some foreign countries,
to actually go by a new laptop is virtually impossible since all
of the expense is out of pocket. The particular chunk of code uses
"if ... elseif" clauses to clunk through every version of Adobe
back to 4.0, and across the society, I'm sure everyone of them
runs on at least one laptop.

All of that was working for everyone but me ... of course ...
because my new system is, since I'm a developer, 2 meg with Vista
64 Ultimate.

Better than Environ, is there a Do.Cmd that would acquire the OS
version and platform, whether 32 or 64?

If you explained somewhere in there why .FollowHyperlink is
unsatisfactory, I missed it. Is there a circumstance under which it
will break? If not, then why not use it?

 

[Gary G. Little]

Mostly because I've only been working with Access 2007 for about 3 months,
and had not bothered to look at the 2000 docs, which is where I found
FollowHyperlink. But from what I see of FollowHyperlink, it looks like I
need to know the path of the application, which means I'm back at
determining 32 or 64 bit OS to know whether to use the "(x86)" suffix or
not.

Thank you for the reply.

Gary

 

[Rick Brandt]

Mostly because I've only been working with Access 2007 for about 3
months, and had not bothered to look at the 2000 docs, which is where
I found FollowHyperlink. But from what I see of FollowHyperlink, it
looks like I need to know the path of the application, which means
I'm back at determining 32 or 64 bit OS to know whether to use the
"(x86)" suffix or not.

No, for FollowHyperlink you only need to know the path to the file. It is
functionally the same as double-clicking a file. It is up to Windows to
know what program to use to open the file and where that program is located
(providing that it is a registered file type).

 

[Gary G. Little]

One final question: Is there a way to allow a PDF to be displayed under
Vista and Access 2007 without getting the security waraning for hyperlinks?
This comes after searching, and not just asking questions.

Gary

 

[Tony Toews [MVP]]

One final question: Is there a way to allow a PDF to be displayed under
Vista and Access 2007 without getting the security waraning for hyperlinks?

See API: Start an app with ShellExecute
(Q) How do I start the application which is registered to handle a
file extension in Win Registry?
http://www.mvps.org/access/api/api0018.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Gary G. Little]

Thanks Tony. That did the trick. It was an Access 2007 warning, not an OS or
UAC warning.

 

[mcnews]

I needed to know the OS, whether 32 or 64 bit, so that I could properly set
the \Program Files path to find whatever version of Acrobat is installed.
The 64 bit OS versions use both \Program Files and \Program Files (x86), and
since Acrobat reader is only 32 bits, it installs into the (x86) path. The
problem is that the VB code shells out to the Adobe Reader via an explicit
path based on a 32 bit OS installation and hence can never find the reader
since it always looks in \Program Files and never \Program Files (x86). The
code was developed on 32 bit systems so using that explicit path was
acceptable at the time. With the advent of newer 64 bit systems that
obviously ain't gonna work for everybody.

Trying to resolve the issue with minimal impact, I added this line to the
module:

if Left(Environ("PROCESSOR_ARCHITECTURE"), 5) = "AMD64".

However ... Environ always returns "x86", the if takes the else clause and I
never find the Acrobat Reader. It does this whether I'm under XP 64 Pro on a
dual XEON system, or under Vista 64 Ultimate on a Core 2 Duo T7500. When I
enter a command line and look at the variable it shows "AMD64". It's almost
like ACCESS and VB reload the environment variable(s) because everywhere
else I look at that var it's always "AMD64" and not "x86".

I also tried the PROCESSOR_IDENTIFIER but on the XEON that is "EM64T", but
on the core 2 Duo it i s "Intel64". The solution may be to simply use
Environ("ProgramFiles(x86)").

Anyone else encountered this type of problem?

Gary

speaking of environment....
what's the best way to get the computer's name other than using
environ()?

 

[Douglas J. Steele]

http://www.mvps.org/access/api/api0009.htm at "The Access Web"