Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice Topic is solved

[wad11656]

I am deploying .exe program launchers to multiple computers in our company. Some users have the x86 version of MS Suite/Acrobat/Chrome, and some have the x64 version.

To bypass needing to identify whether the x86 or x64 version of software is installed, I'm using the Run command.

WinWord.exe, excel.exe, acrobat.exe all work great in the Run prompt from the start menu.

image.png (9.12 KiB) Viewed 733 times

But AutoHotkey's Run is inconsistent.

Here's what happens when I try to run a script that simply has Run, EXCEL.EXE:



Additionally, Run, WinWord.exe and Run acrboat.exe scripts both usually have to be run twice before it actually starts opening the respective program.


However, Run, chrome works fine:


Any ideas on how to run the WinWord.exe, excel.exe, and acrobat.exe Run commands without errors or needing to run the script twice?

[kintar0e]

Maybe with cmd

Code: Select all

Run, %ComSpec% /c start winword

[FanaticGuru]

I am deploying .exe program launchers to multiple computers in our company. Some users have the x86 version of MS Suite/Acrobat/Chrome, and some have the x64 version.

To bypass needing to identify whether the x86 or x64 version of software is installed, I'm using the Run command.

WinWord.exe, excel.exe, acrobat.exe all work great in the Run prompt from the start menu.

This works fine for me.

Code: Select all

Run, WinWord
Run, Excel
Run, Acrobat

This simple script opens all three programs nearly simultaneously every time without a problem for me on multiple computers.

So not much of a solution but maybe it helps to know it is not a universal problem but specific to your setup.

FG

[flyingDman]

Code: Select all

Run, WinWord
Run, Excel

Work as expected here as well.

[BoBo]

"… fritzes out" … https://www.quora.com/Where-did-the-phrase-on-the-fritz-come-from (the answer by Brian Roemmele)

The Katzenjammer Kids/Hans & Fritz

[wad11656]

"… fritzes out" … https://www.quora.com/Where-did-the-phrase-on-the-fritz-come-from (the answer by Brian Roemmele)

The Katzenjammer Kids/Hans & Fritz

Hah-That's super interesting

Maybe with cmd

Code: Select all

Run, %ComSpec% /c start winword

Thank you -- This helped with all of them except Excel.

EDIT: Obviously a primary conclusion we can draw from this thread is that something is wrong with my Windows installation that is causing Run() to misbehave. Thus, the arguably "real" solution would be to reinstall Windows or identify-and-uninstall the conflicting software that is leading to Run()'s unexpected behavior. But if you'd like to read about a more reliable Run() alternative that worked for me as a workaround, read below.

The solution for Excel, which I found here, was to use Microsoft's ShellExecuteEx via @lexikos' ShellRun (available as ShellExecute in AutoIt):

Code: Select all

ShellRun("excel") ;or EXCEL.EXE/excel.exe/ExCeL.eXe/Excel/ExCeL, etc.

ShellRun(prms*)
{
    shellWindows := ComObjCreate("Shell.Application").Windows
    VarSetCapacity(_hwnd, 4, 0)
    desktop := shellWindows.FindWindowSW(0, "", 8, ComObj(0x4003, &_hwnd), 1)
   
    ; Retrieve top-level browser object.
    if ptlb := ComObjQuery(desktop
        , "{4C96BE40-915C-11CF-99D3-00AA004AE837}"  ; SID_STopLevelBrowser
        , "{000214E2-0000-0000-C000-000000000046}") ; IID_IShellBrowser
    {
        ; IShellBrowser.QueryActiveShellView -> IShellView
        if DllCall(NumGet(NumGet(ptlb+0)+15*A_PtrSize), "ptr", ptlb, "ptr*", psv:=0) = 0
        {
            ; Define IID_IDispatch.
            VarSetCapacity(IID_IDispatch, 16)
            NumPut(0x46000000000000C0, NumPut(0x20400, IID_IDispatch, "int64"), "int64")
           
            ; IShellView.GetItemObject -> IDispatch (object which implements IShellFolderViewDual)
            DllCall(NumGet(NumGet(psv+0)+15*A_PtrSize), "ptr", psv
                , "uint", 0, "ptr", &IID_IDispatch, "ptr*", pdisp:=0)
           
            ; Get Shell object.
            shell := ComObj(9,pdisp,1).Application
           
            ; IShellDispatch2.ShellExecute
            shell.ShellExecute(prms*)
           
            ObjRelease(psv)
        }
        ObjRelease(ptlb)
    }
}

In fact, since this seems to be the most reliable method of launching exe's (even though nobody else in the thread had the same issues as me), and I'm assuming it's closer to what the Run dialog uses (since that works for me whereas AHK's Run() gives me the inconsistent behaviors described above), I've transformed the rest of my exe launch scripts to use ShellRun() instead as well:
ShellRun("acrobat") ShellRun("winword") ShellRun("chrome")

[flyingDman]

You are marking it Solved but I hope you realize that it is just a bandaid. Your PC does not work properly and if no other solution is found I would consider reinstalling Windows.

[wad11656]

You are marking it Solved but I hope you realize that it is just a bandaid. Your PC does not work properly and if no other solution is found I would consider reinstalling Windows.

Obviously my PC is not working properly, based on the successful tests performed in this thread. However, I found it more useful for future community members/Googlers for me to highlight the seemingly-more-reliable alternative, ShellRun(), than to focus on the fact that my PC is messed up and I need to reinstall Windows. This wouldn't be a very helpful "solution" to highlight for future Googlers because my Run() issues seem quite unique to my setup, and reinstalling Windows is a "solution" that future readers of this thread would probably not be eager to perform. Run() is also the only command I've had issues with after using AHK for over a year on this PC, so I'm not considering reinstalling Windows simply because of that. Also, my "band-aid" (ShellRun()) is, as far as we know at this time, a permanent, universal, and more reliable solution than Run() (based on my own experience and that of the person in the linked thread), so it's a pretty darn good "band-aid" and I might as well keep using it.