Shell command to open outlook 2013 not working 1

[1DMF]

Hi,

I have an email class that tries to check if outlook is open and if it isn't it opens it.

This code has worked in Office 2003, 2007 & 2010 , but has stopped working in 2013?

The command is

Call Shell("Outlook.exe")

But that errors with

53 - File not found

Do I need to change some environment variable to ensure some other path is included in the search location for executable?

I've found the Outlook.exe here : C:\Program Files\Microsoft Office 15\root\office15

So why can't windows find it when the shell command is issued?

Thanks,
1DMF




"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

Well I have been looking at the app path reg key and everything looks fine.

They have the following entry

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE

Which has the correct path to the Outlook application file.

However, if I drop to cmd and type outlook.exe , I get the error regarding file / command not recognised.

If I paste the path from the reg-key entry into the explorer address bar, Outlook opens, so the path is correct.

Why isn't the reg_key working and outlook opening when just the exe is attempted to be executed without a full path?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

OK, this reg key appears to do nothing, because it isn't assisting with locating an app when attempted to run via shell / command line.

No office app works this way, winword.exe, msexcel.exe, outlook.exe etc..

Office is not in the PATH environment variable.

Look like I've got to go to the office forum and find out how the hell you get Office 2013 to register itself correctly.




"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

I have resolved my problem with the following code.

Dim ws As Object
Dim sPath As String
Set ws = CreateObject("WScript.Shell")
sPath = ws.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE\")
Set ws = Nothing
Call Shell(sPath)

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

I often use something like the following:

[blue]Option Explicit
Const olNormalWindow = 2

Public Sub OpenAndDisplayOutlook()
    Dim outlook As Object
    
    Set outlook = wombat
    outlook.Session.GetDefaultFolder(olFolderInbox).Display
    outlook.ActiveExplorer.WindowState = olNormalWindow
End Sub

Public Function GetOutlook() As Object
    Dim result As Object
    On Error Resume Next
        Set result = GetObject("Outlook.Application")
        If result Is Nothing Then
            Set result = CreateObject("Outlook.Application")
        End If
    On Error GoTo 0
    Set GetOutlook = result
End Function[/blue]

 

[1DMF]

I already use

' Check Outlook helper
Private Function CheckOutlook() As Boolean

On Error GoTo Outlook_Error
    
    CheckOutlook = True
    
    Dim olApp As Object
        
    ' Check outlook
    Call AddProgress("Checking Outlook is open.")
    
    Set olApp = GetObject(, "Outlook.Application")
    
    Set olApp = Nothing
    
    Exit Function
    
Outlook_Error:

    ' Outlook not open
    If err.Number = 429 Then
        Call AddProgress("Trying to open Outlook.")
        
        ' read registry to find out where the hell Outlook is installed.
        Dim ws As Object
        Dim sPath As String
        Set ws = CreateObject("WScript.Shell")
        sPath = ws.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE\")
        Set ws = Nothing
    
        ' open outlook
        Call Shell(sPath)
        Sleep 1000
        Resume Next
    Else
        CheckOutlook = False
        Call AddError(99, err.Source & " - " & err.Description & "-CheckOutlook")
    End If
    
End Function

To check it's open, and my shell command worked fine until Office 2013 to open it?

What on earth is wombat?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>What on earth is wombat?

You clearly haven't been in the VB5/6 forums long enough ... ;-)

But in this case it should be replaced by GetOutLook

> my shell command worked fine until Office 2013

Lucky ...

If the file name does not contain a directory path, the system searches for the executable file in the following sequence:

1.The directory from which the application loaded.
2.The current directory for the parent process.
3.The 32- or 64-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
4.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5.The directories that are listed in the PATH environment variable.
6.The per-application path specified by the App Paths registry key - either the 64bit entries or the 32bit entries (via registry reflector)

Only option 6 is applicable here, but that doesn't tell the whole story ... have a quick look here: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths and see if Outlook.exe is there.

 

[1DMF]

I think you missed some of my post Mike.

6.The per-application path specified by the App Paths registry key - either the 64bit entries or the 32bit entries (via registry reflector)

Wasn't working, the reg key exists (including Win6432Node) and the path it has is correct, it just wasn't looking there, couldn't have been otherwise

Call Shell("Outlook.exe")

would have still worked.

I don't know why only users running Office 2013 were behaving like this, because as soon as I altered my code to read the path from the reg_key and use that instead, it works again for all users be them on Office 2007 / 2010 / 2013 - yet to test on 2016!

You clearly haven't been in the VB5/6 forums long enough ...

So is wombat an acronym or a punchline to a forum joke I'm not in on?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

I read all your post, which is why I suggested looking at the Win6432 node, as this may have been a 64bit v 32bit issue (specifically VBA is 32 bit unless you deliberately opted for 64bit version). 32bit Shell method will not be reading HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths, it would (in theory) be reading HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths.

But if you have correct entries in Wow6432Node that actually suggests that somewhat unexpectedly Shell is not looking in the at App Paths at all. And a quick check on an old XP box with Office 2010 exhibits the same behaviour ... and Process Monitor shows that App Path is not searched AT ALL. Which is, erm, odd.

Hmmm.

As for wombat ... a quick search in the VB5/6 forum against the keyword wombat might be vaguely illuminating, if you are that curious.

 

[1DMF]

Thanks Mike, glad I had come to the right conclusions that for some bizarre reason Office 2013 was behaving funky.

But why would this be Office related, isn't this Windows related?

From your tests, you have XP & Office 2010 doing the same thing?

All my Office 2010 users worked fine and I checked my PATH variable (I have Office 2010) and there isn't any mention of Office in it, so one assumes the shell was not reading the App Path.

Oh well, I have found a resolve, so I guess it's all academic now.





"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

Further investigation seems to indicate that it is definitely a problem with VB's shell command, which clearly is not wrapping the normal ShellExcute or ShellexecuteEx from Shell32.dll (these are the two API calls that exhibit the system search described several posts above).

So we can fix that. Here's a couple of ways. First example most closely resembles the built-in Shell command, as it returns a 'TaskID'

[blue]Public Type SHELLEXECUTEINFO
    cbSize As Long
    fMask As Long
    hWnd As Long
    lpVerb As String
    lpFile As String
    lpParameters As String
    lpDirectory As String
    nShow As Long
    hInstApp As Long
    lpIDList As Long
    lpClass As String
    hkeyClass As Long
    dwHotKey As Long
    hIcon As Long
    hProcess As Long
End Type

Private SEI As SHELLEXECUTEINFO

Private Declare Function ShellExecuteEx Lib "shell32.dll" (SEI As SHELLEXECUTEINFO) As Long

Public Function vbShell(Pathname As String, Optional WindowStyle As VbAppWinStyle = vbMinimizedFocus) As Double
    Dim SEI As SHELLEXECUTEINFO

    With SEI
        .cbSize = Len(SEI)
        .lpFile = Pathname
        .nShow = WindowStyle
    End With
    ShellExecuteEx SEI
    
    vbShell = SEI.hInstApp
End Function[/blue]

Second example is somewhat shorter ...

[blue]Public Sub vbShell2(Pathname As String, Optional WindowStyle As VbAppWinStyle = vbMinimizedFocus)
    CreateObject("shell.application").ShellExecute Pathname, , , , CLng(WindowStyle)
End Sub[/blue]

 

[1DMF]

Wow, certainly not how I looked at solving it - always impressive when you get involved!

It still doesn't explain why it only affected users with Office 2013 if it's the VBA shell command and everyone is running the same app on Access 2010 runtime?

I did a test

Private Sub test3_Click()
    vbShell2 ("Outlook.exe")
End Sub

Public Sub vbShell2(Pathname As String, Optional WindowStyle As VbAppWinStyle = vbMinimizedFocus)
    CreateObject("shell.application").ShellExecute Pathname, , , , CLng(WindowStyle)
End Sub

Which worked on both 2010 and 2013 users machines, though it seemed a little slower / clunky on 2013?

So do I stick with reading the reg-key myself and executing outlook with the full path or refactor to use your shell code?



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>It still doesn't explain

Indeed it doesn't. I'd suspect that a windows/office update has changed something.

>So do I stick with reading the reg-key myself

Your call!

 

[strongm]

One quick question, though - what is the path to Access? I ask because it is entirely possible that previous versions worked OK because Access and Outlook were installed in the same directory, and thus Shell, searching either

1.The directory from which the application loaded.
2.The current directory for the parent process.

finds Outlook.

 

[1DMF]

Each access app runs from its installed path on the C:\ Drive...

I use the Solution Packager to create an application MSI and that adds the required trusted reg_key, install the app to the C:\Drive and adds a shortcut with icon to the user's desktop.

Access is the 2010 runtime and in the following path, C:\Program Files(x86)\Microsoft Office\Office14



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

Ok, well, that would do it, since searching that folder won't find Outlook. But, if you had Outlook 2010 installed it would be in that folder, and would therefore be found ...

And the reason I had similar symptoms is that I was running from a very different folder ...

 

[1DMF]

if you had Outlook 2010 installed it would be in that folder

That's not strictly true, found office here : C:\Program Files\Microsoft Office 15\root\office15

But I don't get it , they aren't running 64bit Office (I checked), plus you can't mix and match 64/32, so the runtime is 32bit, the app is 32bit and Office is 32bit, but it's not in the 32bit program folder?

I installed it from the office account download link and left everything on default such as folder paths etc..

There is only this in the (x86) 32bit folder...

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>That's not strictly true, found office here : C:\Program Files\Microsoft Office 15\root\office15

Office15 is Office 2013, not 2010.

The point is that Access's VBA Shell method

a) does NOT examine the App Path registry key (whether 32bit or 64bit)
b) is running from a process that is launched from a directory that does not contain outlook.exe, nor is outlook.exe in the current directory for the parent process (you've already clarified that outlook.exe is in the Office 15 folder, whilst your application is in office 14)

i.e. If you only had office 2010 installed, all would be well, since the Access 2010 runtime would be in the same folder as outlook 2010. The moment you install Outlook 2013 you'd run run into a problem since it would be installed into the Office 15 folder (and by default uninstalls Outlook 2010). Of course, if you were using the Access 2013 runtime, all would be well again ...

So now all is clear!

 

[1DMF]

a) does NOT examine the App Path registry key (whether 32bit or 64bit)

sorry, I thought you were saying that it should normally. and the point I was making is that the 64/32 seems screwy, why is 32bit Office installed in the non x86 program folder?

So now all is clear!

yes, thanks

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music