Closing a program with script...

[Guest]

I am looking for some assistance in locating who to or perhaps some sample
script for closing a running program. I am having difficulty with people
shutting down app's when they go home for the evening. Perhaps something
that I can Task Schedule to run every evening.

Thanks
David

 

[Gary S. Terhune]

What apps? Oddly enough, while it's easy to run an app using a VB script, I
find no method to easily exit an app. But here's one example of a kludge
that will work for some apps. Using calculator as an example (calc needs to
already be open):

dim WshShell
set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.AppActivate "calculator"
WshShell.SendKeys "%{f4}"
WScript.Quit

Problem is, to identify the application and activate it requires the name of
the app as it appears in the title bar, or the Process ID. I'm not sure how
to obtain a Process ID, but that's what you'd want. Using the title of the
app is not useful in many cases, because it varies. For example, while the
title bar for Calculator is always the same, apps like Word and IE list the
open document's name, followed by the app's name, like this: "My Test
Document - Microsoft Word".

I'm curious: Why it's important that the apps be closed in the first place.

 

[Guest]

Thanks for the assist. I will give this a try. Reason being, there certain
DB utilities I run on a weekly basis. And with users still login into the DB
I have to go to each work station, or remote in to log them out.

 

[Pegasus \(MVP\)]

You can obtain the process ID of an active task, e.g. for
Firefox, with this command:
for /f "tokens=2" %a in ('tasklist ^| find /i "Firefox"') do echo %a

Here is the script equivalent:
Option Explicit
Const App = "FIREFOX"
Dim ObjWshShell, ObjExec
Dim ComSpec, SystemRoot, line

Set ObjWshShell = WScript.CreateObject("WScript.Shell")
ComSpec = ObjWshShell.Environment("PROCESS")("ComSpec")

Set ObjExec = ObjWshShell.Exec(ComSpec & " /c tasklist.exe")

line = ObjExec.StdOut.ReadLine
line = ObjExec.StdOut.ReadLine
While Len(line) > 0
If InStr(UCase(line), App) > 0 Then
line=LTrim(Right(line, Len(line) - InStr(line," ")))
WScript.Echo("Process ID for """ & App & """ is " &
Left(line,InStr(line," ")))
End If
line = ObjExec.StdOut.ReadLine
Wend


http://www.stadt-solothurn.ch/de/aktuelles/aktuellesinformationen/?action=showinfo&info_id=54610

 

[Gary S. Terhune]

You'll find this reference handy:
http://msdn2.microsoft.com/en-us/library/8c6yea83.aspx

 

[Gary S. Terhune]

After fixing the line return problems in the script, engendered by NG
transfer, I can't make it work. I get a command window flashing by, then
nothing. I'm using Calculator as a test, rather than Firefox, which I don't
have installed. Tried it in a command window, also, with no return. Tried
with Calc open and with it closed.

Using the command line in a command window, I get "'Tasklist'" is not a
recognized internal or external command, operable program or batch file."

 

[Pegasus \(MVP\)]

Tasklist.exe is a standard WinXP command. It resides in the
System32 folder. If I had to resolve this issue then I would
perform these steps from a Command Prompt:
- Check if tasklist.exe exists in the System32 folder.
- Invoke it from the Command Prompt.
- Ensure that the path includes the System32 folder.
- Check if the batch file version works.

 

[Gary S. Terhune]

Doh... There's the problem. TASKLIST.EXE doesn't exist on this system,
anywhere. Weird. But then again neither do this user's TIF index.dat or
History index.dat files (referring to another thread), but part of that may
be because when I set it up, I changed the TIF directory to a different
partition. (It's my wife's business machine and I don't dare mess with it
too much now.)

Guess I'll have to wait till I get back to my own machines to get any
farther.

 

[Paul Randall]

The command line reference a-z supplied with WXP tells you about
tasklist.exe. On my computer it resides in my system32 folder.

-Paul Randall

 

[Gary S. Terhune]

Like I said, tasklist doesn't exist on this system. Turns out it's Home
Edition. I'd forgotten about that. SysInternals' Process Explorer gives the
info, but the PID varies for any one app. Assuming Tasklist.exe on the OP's
system, he would have to use your script to return the PID and then use my
SendKeys example to terminate it (or maybe a better method exists.)

Even then, while it works with calc, my experimentation using WinWord for
some reason fails. The app activates, but the SendKeys doesn't work...Odd...
There's also the issue of dealing with any possible prompts for things like
unsaved files...

 

[Gary S. Terhune]

Never mind, it works. While SendKeys doesn't work well if the window isn't
actually brought up (AppActivate doesn't actually pull up the window) the
use of Alt-F4 works for any of them. But this other thing would need to be
dealt with: Say you have two instances of an app like Word open. AppActivate
only activates one of them, arbitrarily. The remaining instance would have
the same PID, so the script would need to loop through the same PID until
none was found to exist. The script generates no errors using AppActivate if
the PID doesn't exist. It just skips on by. AppActivate supposedly returns a
Boolean value, but damned if I can retrieve it. Brain is getting foggy.

 

[Gary S. Terhune]

My mistake, using the title, e.g., "Microsoft Word" works just fine. I was
encountering a different error. AppActivate will look at the title in
various ways until it finds one that fits. Thus, Process ID isn't necessary.

But after thinking about it, why not look into EndItAll? Not sure, but I
presume there is a simple way to run it from a command line or script. Gets
rid of the need to figure out what's open that needs closing. Or, you can
force a reboot and then run your utilities. Of course, if anything needs
saving, that last suggestion will force the reboot and the save will not
occur. Then again, that's only really a problem for your lazy users, isn't
it?

 

[Pegasus \(MVP\)]

If you have several applications of the same name then each
has its own PID. Switching to that PID and using Alt+F4
would kill each application individually.

A more effective method might be to use taskkill.exe (another
WinXP Professional tool):

taskkill /PID nnn /f
taskkill /Im Winword /f

The /f switch would take care of user prompts.

 

[Gary S. Terhune]

Using Process Explorer to see the PID, launching several instances of Word
only generates one PID. Have to repeat the close procedure until all are
closed. Launching several instances of IE behaves as you describe.

Taskkill looks more interesting, but it still requires that the script
identify apps that are open that need to be closed, as opposed to services,
etc., that you don't want killed.

I think EndItAll is probably the best solution.