Problem automating Outlook in Windows 7 from VB6 and Access

  • Thread starter Thread starter Tony Toews
  • Start date Start date
T

Tony Toews

Folks

I have a a VB6 EXE (Auto FE Updater if anyone cares) which does a
bunch of things and then starts up Microsoft Access. A user, who has
done some good troubleshooting, has a problem within Windows 7.

If he starts up the Access FE MDE file with the VB6 exe it fails on
the following line of code.
Set olApp = GetObject(, "Outlook.Application")
if Outlook is already running. A second copy of Outlook briefly
appears in the taskbar.

If Outlook isn't already running then it works. But of course most
folks who run Outlook in a corporate environment run it all the time.

If he starts up the Access FE MDE with a batch file it works just
fine.

If he clicks on the Access FE MDE from Windows Explorer it works just
fine.

All of the above works just fine on a Windows XP system. This
problem is new to Windows 7

This sounds suspiciously like a permissions problem of some sort I had
when Win Vista first came out and I had to put in a manifest file in
the VB6 exe.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
Hi Tony,

Posting to a dead newsgroup? <g>

I've seen similar with automating Word or Excel from an Outlook addin in 2
circumstances.

First, if different SKU's are being used (Outlook 2010 and Word or Excel
2003 for example).

The other circumstance is differences in invocation permissions. I use
asInvoker in my manifests for my VB6 Outlook addins. If Word is started
using "as admin" and then I try to use GetObject() on that instance from my
Outlook addin (started "as invoker") when Outlook was started normally that
will cause problems.
 
Posting to a dead newsgroup? <g>

Absolutely. I figure the die hard experts are still going to be in
the "dead" newsgroups. And here you are!
I've seen similar with automating Word or Excel from an Outlook addin in 2
circumstances.

First, if different SKU's are being used (Outlook 2010 and Word or Excel
2003 for example).

Yikes, that's a pain.
The other circumstance is differences in invocation permissions. I use
asInvoker in my manifests for my VB6 Outlook addins. If Word is started
using "as admin" and then I try to use GetObject() on that instance from my
Outlook addin (started "as invoker") when Outlook was started normally that
will cause problems.

Ahhhh. However in this case presumably the folks are all users and
not admins.

The following is the manifest file I had to create for Windows Vista
to add as a resource to my VB6 program.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
You're using asInvoker also, but if a user right-clicks and "Runs as
Administrator", or some other app automates and has "asAdmin" in its
manifest then it gets ugly. I'm not saying that's it, but it's the first
thing I'd try to eliminate. The security stuff can get confusing and ugly
for sure.

So are you saying that if your user double-clicks on the exe he sees the
problem if Outlook is already running, but if he starts the exe from a bat
file there is no problem? That's pretty wacky all right.

Have you asked Karl to review the problem? He might know something about
GetObject() and Win7. He's always digging around with that sort of thing.
 
You're using asInvoker also, but if a user right-clicks and "Runs as
Administrator", or some other app automates and has "asAdmin" in its
manifest then it gets ugly. I'm not saying that's it, but it's the first
thing I'd try to eliminate. The security stuff can get confusing and ugly
for sure.

Highly unlikely but I'll point him to these threads so he can monitor
them himself.
So are you saying that if your user double-clicks on the exe he sees the
problem if Outlook is already running, but if he starts the exe from a bat
file there is no problem? That's pretty wacky all right.

Correct. Of course the problem though is that my VB6 exe starts up
Access which in turn does the Get/Create Object to Oulook. So it's
getting real ugly.
Have you asked Karl to review the problem? He might know something about
GetObject() and Win7. He's always digging around with that sort of thing.

Yup, I've got a thread going over in the MS VB6 newsgroup but decided
I'd ask over here as well just in case.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
First, if different SKU's are being used (Outlook 2010 and Word or Excel
2003 for example).

His response to your and others questions.

Everything is 32 bit, Windows and Office.

The rest of the users (about 15) are running Office 2007 on Windows
XP, and this works fine. Some are on Office Pro, some are on Office
Standard with Access Runtime.

The logged in User on the new Win 7 machine is a standard user, not
admin. The new PC has Office Pro.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
I'm lost then. I have no idea why one way would fail and not the running of
a bat file. It doesn't sound like security.

Have them just start things with a batch file and put a shortcut to it
somewhere convenient?
 
I'm lost then. I have no idea why one way would fail and not the running of
a bat file. It doesn't sound like security.

Have them just start things with a batch file and put a shortcut to it
somewhere convenient?

My VB6 utility is exceedingly convenient for a wide variety of
reasons.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
I didn't say it wasn't convenient, I suggested providing an alternate way of
starting it on Win7 if you can't figure out why it isn't working there. I
really don't know why the batch file would work and directly starting the
code wouldn't work.
 
I didn't say it wasn't convenient, I suggested providing an alternate way of
starting it on Win7 if you can't figure out why it isn't working there. I
really don't know why the batch file would work and directly starting the
code wouldn't work.

Hold on a sec here. The problem occurs when my VB6 utility starts
Access. Access then does the Get/Create Object. When they start
Access via a batch file or directly via Windows Explorer then it works
just fine..

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
I misunderstood what you were getting at. I thought the problem was when
starting your app directly versus via a batch file. So it's how Access is
started, and then the Access code starts Outlook. OK, I understand now but
I'm still mystified. Other than the security aspects that were already
discounted I can't think of any reason for what's happening.
 
Back
Top