Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice Topic is solved
Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
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.
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?
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.
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?
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
Maybe with cmd
Code: Select all
Run, %ComSpec% /c start winword
- FanaticGuru
- Posts: 1907
- Joined: 30 Sep 2013, 22:25
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
wad11656 wrote: ↑19 Sep 2022, 18:05I 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
So not much of a solution but maybe it helps to know it is not a universal problem but specific to your setup.
FG
Hotkey Help - Help Dialog for Currently Running AHK Scripts
AHK Startup - Consolidate Multiply AHK Scripts with one Tray Icon
Hotstring Manager - Create and Manage Hotstrings
[Class] WinHook - Create Window Shell Hooks and Window Event Hooks
AHK Startup - Consolidate Multiply AHK Scripts with one Tray Icon
Hotstring Manager - Create and Manage Hotstrings
[Class] WinHook - Create Window Shell Hooks and Window Event Hooks
- flyingDman
- Posts: 2822
- Joined: 29 Sep 2013, 19:01
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
Code: Select all
Run, WinWord
Run, Excel
14.3 & 1.3.7
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
"… 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
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice Topic is solved
Hah-That's super interestingBoBo wrote: "… 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
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)
}
}
ShellRun("acrobat") ShellRun("winword") ShellRun("chrome")
Last edited by wad11656 on 07 Oct 2022, 03:52, edited 1 time in total.
- flyingDman
- Posts: 2822
- Joined: 29 Sep 2013, 19:01
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
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.
14.3 & 1.3.7
Re: Inconsistent "Run" behavior: "Run, EXCEL.EXE" fritzes out; "Run, WinWord.EXE" has to be run twice
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.flyingDman wrote: ↑06 Oct 2022, 18:29You 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.