Hi,
Post by David WhiteHello,
I am trying to use AppActivate to activate Norton Ghost
2003's main window prior to using SendKeys to automate
Ghost's behavior on my system.
[snip]
Does anyone have any idea why this is happening and what I
can do to get things working? Thanks in advance.
The problems with AppActivate are legion, and your situation could fall into
one or more of them. Here's my standard schpeal, but first the url for
AutoItX, if you can install an ActiveX on your machine. Highly recommended
as far more articulate and reliable.
http://www.hiddensoft.com/AutoIt/
There are a number of undocumented issues with the Shell.AppActivate method
and function that significantly limit its usefulness. As a summary of its
operation, on Win98, WinMe, Win2k and WinXp, it will not access minimized
windows; it will only access restored or maximized windows. In addition, on
Win2k and WinXp, the foreground lock option may prevent activation.
Finally, there are other issues with title strings. With articulate use, it
remains functional for new windows opened in restored or maximized mode,
existing windows known to be currently in restored or maximized modes, and
system-modal windows on controlled versions of Windows, with generated
simple title strings or titles known through experience.
Minimized Windows
On Win98, WinMe, Win2k and WinXp, when the specified window is minimized
Shell.AppActivate will not restore it or activate it, and the function will
generally return as false. If the script does not involve a new window, one
of otherwise known status, or a system-modal window, then the only
work-around to this major undocumented problem is to use a third-party
utility or ActiveX, of which AutoItX appears to be the most widely
recommended.
Foreground Lock
On Win2k and WinXp, the system allows the user to prohibit a window from
"stealing focus" on the desktop, through a foreground lock, which is
activated by default when WinXp is installed. When set, this user option
prevents window activation through external means, such as Shell.AppActivate
and most third-party ActiveXs or utilities. If the foreground flash option
is also set, the taskbar button for the window will flash.
The thorough work-around for this is systemic; there is no work-around on a
script-by-script basis. The foreground lock can be canceled for each user
through the TweakUI utility, or by permanently setting the registry
foreground lock value, HKEY_CURRENT_USER\Control
Panel\Desktop\ForegroundLockTimeout, to a dword of zero (0). The default
value data is 0x0030D40 or 200000 ms. To be effective, the current user
profile then has to be updated, generally by logging off and on. This
requirement prevents individual scripts from simply reading the registry
value, setting it to zero prior to the call, then resetting it to the
original value afterwards. Otherwise, an updated third party ActiveX or
utility can be used. AutoItX apparently addressed this problem in v2.62,
and since that version, seems to handle the issue reasonably well.
Script-Modal Windows
Most inherent dialog windows other than IE windows are script modal and
cannot be directly activated from the calling script. The traditional
solution is to write and run a secondary VBS script file in the user's
temporary folder immediately prior to calling the inherent dialog, using the
Shell.Run method, without waiting on the secondary VBS file to complete.
The Shell.AppActivate function can be used in the secondary script in a loop
to wait for a period of time the dialog window to open, by attempting to
activate it at set intervals. Some anti-virus software (most notably
Norton) will flag secondary VBS files as "malicious" and halt their
operation, unless the software has been set to allow VBS files.
Window Title String Issues
The Shell.AppActivate title string buffer is apparently limited to 16
characters, the method searches only for the initial (leftmost) window title
characters, and the search is case insensitive. All this can produce
confusion as to the window title sought in a multiple-window environment.
The only title-string work-around for this issue is to use a third-party
utility or ActiveX, again such as AutoItX, which allows for long titles, has
a case sensitive search, has settings testing initial or any title text, and
can also test for non-title window text.
Some applications have characters in their titles that apparently have
secondary flags set, and are not recognized by Shell.AppActivate in a title
string search. (E.g., using wordperfec causes the function to return as
true and activates the WordPerfect 10 ? ... window, while using wordperfect
causes the function to return as false and does not activate the window.)
The best title-string work-around for this issue is, again, to use a
third-party utility or ActiveX, again such as AutoItX, which does not appear
to be affected by these characters. In lieu of a third-party alternative,
test Shell.AppActivate on the particular windows that it is intended to
activate, and shorten the title search strings, if necessary, to the point
where the procedure works. If that alternative is not available, then
assume that the suspect characters are most likely to be the final
characters in words, and shorten the search string to the first word, less
its final character.
Finally, as documented, if the effective title search string provided could
apply to more than one window title, the Shell.AppActivate function may
return as true, and the method may activate one of those windows. But, if
there are two or more windows open with fully identical titles, the function
may return as false, and the method may not activate any window. Again, the
only title-string work-around for this issue is to use a third-party
utility, such as AutoItX, which appears to operate properly under
multiple-identical-title circumstances and also has window text-recognition
to differentiate between identically titled windows.
As a work-around to all the title-string issues, the documentation obscurely
mentions, without any explanation, that Shell.AppActivate will accept a
process id number in lieu of a window title string. The difficulty, of
course, is in obtaining a window's process id number. If the application
can be initiated with the Shell.Exec method, then a process id number can be
obtained through the method's ProcessId property. As an alternative, if the
application or process can be started through WMI's Process class, then that
method will then return a process id number as a byref argument. If the
application or task is started through some other means, then it may be
possible (but very problematic) to get a process id number through the WMI
Process class.
Credits
Torgeir Bakken (MVP) has posted numerous warnings concerning the
difficulties with the Shell.AppActivate method and minimized windows.
Michael Harris (MVP) posted the foreground lock issue and registry value.
The 16-byte limit was discovered and posted by Tom Lavedas. The
multiple-identical-window-title effect was discovered during an extended
thread with Gurgen Alaverdian, and tested by trial and error. The code for
the Shell.Exec process id example was derived from examples posted by
Michael Harris and Christoph Basedau. The code for the WMI Process class
process id example was derived from examples posted by Michael Harris and
Torgeir Bakken.
Joe Earnest