Change Default Program via Code

S

Scott

I need to use code to change the default program that will open a file.
Can someone help me with a starting point for how to do this?

Here's the situation... I am dynamically creating PowerPoint files out
of Access. To do this, I create the files in PowerPoint .mht format.
The .mht is a PowerPoint format for a, "Single File Web Page." (The
users need the reports in PowerPoint, which is why I've gone to the
trouble of outputting the files to this format.)

Here's the problem....
When a user clicks on an .mht file, Windows opens it with a Web
browser.

I already have Access open the file in PowerPoint immediately after
creation. The problem occurs when the user accesses the file later,
clicking directly on the file.

As a result, I need to change the default program for these .mht files,
setting them to open with PowerPoint instead of Internet Explorer. I
would like to have Access check if the user has an "incorrect" default
setting in the registry, then make the change when needed.

Can someone offer me a starting point?

Thanks in advance!
 
B

BruceM

I just need to say that I don't know how to solve the situation you
describe, but it can't be by editing a user's registry, changing a user's
file associations, or otherwise tampering with a user's computer through
code. Does the file not work correctly in a web browser?
 
K

Klatuu

I'm with Bruce on this one. If I knew somebody was monkeying with my
regsitry or any settings on my computer, I can guarantee you his car would
not start when he tried to go home.

Why can you not create the file in the standard .ppt format? If that is not
an option, the only other thing to do would be to educate the users to open
Powerpoint first and then open the file. You could also create a shortcut
for them that would do that.
 
S

Scott

FYI... I found the answer in a book on Safari Books Online. It's in
chapter 18 of

F. Scott Barker's Microsoft® Access 2000 Power Programming
by F. Scott Barker

--------------------------------------------------------------------------------
Publisher: Sams
Pub Date: June 11, 1999
Print ISBN-10: 0-672-31506-8
Print ISBN-13: 978-0-672-31506-0

It looks like there is an updated version for Access 2002, but that
isn't on Safari.

Since the code isn't mine, I can't post it to help folks... but I can
recommend the book if you need to handle this issue.

If you get the book (or subscribe to Safari), the Barker's registry
utilities are very helpful. Barker walks you through using the Registry
for various things. If you read the book, here are the subroutine calls
I created to change these entries. (These rely on Barker's modules,
which are in the Chapter 18 database examples)

CreateNewRegKey HKEY_CURRENT_USER,
"Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mht"
SetRegKeyValue HKEY_CURRENT_USER,
"Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mht",
"Application", "POWERPNT.EXE", REG_SZ

I hope this saves someone some time in the future.... and pays Barker
back for all the time he saved me today!

Scott
 
S

Scott

Thanks to both BruceM and Klatuu for the responses. I'm sure they were
well intentioned advice.

Regarding the registry... So that anyone reading this in the future
won't be misinformed, here's a quote from the book I referenced in my
last post. Dealing with the registry should be done very cautiously,
but the following quote addresses the fear of using this tool.

---------------------------------------------------------------------
[Quote from F. Scott Barker's Microsoft® Access 2000 Power
Programming]

The Windows Registry, and working with it from VB/VBA, can intimidate
the average Office developer. Mention the Registry, and developers
think immediately of C++-level programming. It seems after developers
get their first assignment requiring manipulating the Registry from
Access using VBA, they try to work on every other task on their plate
before tackling it. This doesn't have to be the case.

By looking at the different parts of the Registry and discussing what
area developers are most likely to use, this chapter will take the
mystery out of it.

You might be saying to yourself, "I have no reason to mess around with
the Registry. Why hassle with it?" One of the first things covered in
this chapter, after a brief history, are reasons for using the Registry
with your applications.

----------------------------------------------------------

Klatuu and Bruce are correct an underlying thought regarding changing
the default program for files... if you need to do this, you should get
the user to approve the change before proceeding.

As an example of a standard approach for this, think of how both
Firefox and Internet Explorer will check if they are the default
browser for Web files. If they find they are not set as default, they
ask the user's permission to change the settting.

I hope this helps any future readers.
 
S

Scott

Thanks to both BruceM and Klatuu for the responses. I'm sure they were
well intentioned.

Regarding the registry... So that anyone reading this in the future
won't be misinformed, here's a quote from the book I referenced in my
last post. Dealing with the registry should be done very cautiously,
but the following quote addresses the fear of using this tool.

---------------------------------------------------------------------
[Quote from F. Scott Barker's Microsoft® Access 2000 Power
Programming]

The Windows Registry, and working with it from VB/VBA, can intimidate
the average Office developer. Mention the Registry, and developers
think immediately of C++-level programming. It seems after developers
get their first assignment requiring manipulating the Registry from
Access using VBA, they try to work on every other task on their plate
before tackling it. This doesn't have to be the case.

By looking at the different parts of the Registry and discussing what
area developers are most likely to use, this chapter will take the
mystery out of it.

You might be saying to yourself, "I have no reason to mess around with
the Registry. Why hassle with it?" One of the first things covered in
this chapter, after a brief history, are reasons for using the Registry
with your applications.

----------------------------------------------------------

Klatuu and Bruce are correct in their underlying thought regarding
changing the default program for files: if you need to do this, you
should get the user to approve the change before proceeding.

As an example of a standard approach for this, think of how both
Firefox and Internet Explorer will check if they are the default
browser for Web files. If they find they are not set as default, they
ask the user's permission to change the settting.

I hope this helps any future readers.
 
Top