Vista - Why won't AutoItX start an instance of Wordpad?

Hi,
I'm trying to use AutoItX to start an instance of Wordpad so I can
manipulate it by VBScripting AutoItX. I've Googled the problem with no joy.
I'm running this on a freshly reinstalled Compaq desktop WXP SP1 system with
most of the crapware uninstalled, and SP3 installed. AutoItX is the latest
version, 3.3.0.0. The Notepad version is different on this SP3 machine
(5.1.2600.5512) is different from my WXP SP2 systems (5.1.2600.2180)

I've included a script that demonstrates the problem. In it, AutoItX
successfully starts mspaint.exe and notepad.exe, but fails to start
wordpad.exe. The script also uses the WSHShell.run method to start
wordpad.exe; this succeeds.

I'm hoping that someone has a similar system and can tell me whether they
have a similar problem, or help me get around the problem.

Option Explicit
Dim oAutoIt
Set oAutoIt = WScript.CreateObject("AutoItX3.Control")
WScript.Echo "oAutoIt.version = " & oAutoIt.version
WScript.Echo "AutoIt starting msPaint; 0 = Failed: " & vbCrLf & _
oAutoIt.Run("mspaint.exe")
WScript.Echo "AutoIt tarting notepad; 0 = Failed: " & vbCrLf & _
oAutoIt.Run("notepad.exe")
WScript.Echo "AutoIt starting wordpad; 0 = Failed: " & vbCrLf & _
oAutoIt.Run("wordpad.exe")

Dim oShell
Set oShell = WScript.CreateObject ("WScript.shell")
WScript.Echo "WSHShell starting Wordpad; 0 = Successful?: " & vbCrLf & _
oShell.run("wordpad.exe")

-Paul Randall

"Paul Randall" <paulr90@xxxxxx> wrote in message
news:O5uNlyqqJHA.3792@xxxxxxPerhaps because wordpad.exe is not in the %path%? Have you tried invoking it
by specifying the full path to its current location?

"Paul Randall" <paulr90@xxxxxx> wrote in message
news:O6AE1HzqJHA.3700@xxxxxxSome applications have an entry in
HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths which allows them
to be invoked without a fully qualified path from the Start/Run button (and,
as you claim, via the WshShell.Run method) but NOT from the Command Prompt.

Unless you run AutoItX on a Windows 98 machine, you should not use
command.com. It is a legacy command processor that lacks many of the
features of the native command processor, cmd.exe. This is the one you
should use.

As always, thanks for your comments.

You were right -- using the full path,
C:\Program Files\Windows NT\Accessories\wordpad.exe,
solved the problem for AutoItX.

I've played around with AutoItX a little more and found:

AutoItX can execute .exe's in path c:\windows\system32 with just the file
name whether the extension is specified or not. AutoItX.run apparently
doesn't check all the paths that WshShell.Run does.

I also tried having AutoItX.run start an instance of command.com, which also
resides in folder c:\windows\system32. It only works if the extension is
specified. WshShell.run doesn't care whether the command.com's extension is
specified.

-Paul Randall

"Pegasus [MVP]" <news@xxxxxx> wrote in message
news:ODsWCxrqJHA.6116@xxxxxx

"Pegasus [MVP]" <news@xxxxxx> wrote in message
news:egKADSzqJHA.1212@xxxxxxwhich is exactly the case for Wordpad/Write. There's a placeholder write.exe
in System32 on recent versions of Windows, but it appears to redirect to the
canonical wordpad application (which on Vista, for example, is "C:\Program
Files\Windows NT\Accessories\wordpad.exe").

Using write.exe works fine. So will using a standard shell execute such as
WshShell.Run's, as noted. The core problem comes back down to the fact that
it _does_ use a different method for invoking an application than AutoIt. I
suspect WshShell uses ShellExecuteEx and that AutoItX uses CreateProcess.
That would also explain the fact that ".com" extensions aren't recognized.
Or use %comspec% as a generic placeholder. In theory that's "more right",
and will work on non-NT Windows. But I always use cmd.exe myself. ; )

"Alex K. Angelopoulos" <aka(at)mvps.org> wrote in message
news:ujBbwmArJHA.588@xxxxxx<snip>
I agree that it is more right to use %comspec% than either cmd.exe or
command.com, but not simply because someone might run your script on a
windows 98 system. IMHO, it is to ensure that the officially installed
command processor is used, regardless of its location. Although I have
rarely run into it, it is possible for windows to be installed to a
different folder or to a different drive from "windows" and "C:".

That said, if a script might be run on xp/nt/2k3, etc *and* possibly on
windows 98 as well, there are a number of other factors that need to be
handled, including:

- batch file extension of .bat instead of .cmd
- different options and parameters for cmd.exe and command.com
- completely different meanings of some of the switches common to both (/e,
I think, is one)
- radically different set of batch programming functionality
- significantly different command-line utilities of the two major different
operating systems.

Some of this can be cleverly done with code that looks and works the same on
all platforms, but sometimes the simplest approach is to test for the o/s
and branch to the o/s specific code required.

/Al