[Closed] IT bore.. using taskkill with a key press?

Don't know of a way with scheduler. We used to use AutoIT to automate Lotus Notes installs back in the day, as there was no effective package management and it would record / send keystrokes - that might be worth a go.

I know I can use the /f parameter to force kill it but then the program doesn’t do its updating etc which is the reason for doing the overnight close.

I'm not sure as I follow the logic here, can you elaborate?

Surely either the updater is part of the program and it's not running [i]because[/i] you've closed it, or it's a separate process in which case force closing it shouldn't make a fig of difference. And in any case, taskkill /f and taskkill [yes] have the same net result, they terminate a process, so what's the difference?

Unless by closing the program gracefully clicking on the OK/Yes button, it then launches a background process to do the updates. And oddly doesn't update if you leave the program open? Bit rubbish design if that's the case, but possible.

What's the program and/or have you checked their documentation for any possible unattended operation modes? unlikely but some do provide an option which lets it suppress prompts.

Ah, good thinking.

TBH, I'd be seeking alternative software which was fit for purpose. If this behaviour is intentional then surely everyone using it would have the same dilemma. Either that or you need to RTFM.

Yeah the program runs updates if you close manually but not if you force close it. I need the updates to run each night on closing but it’s often left on... then it’s my fault in the morning when it doesn’t work properly, so it’s really user error more than anything that I’m trying to eliminate. Pc’s Need to have the program turned off in a certain order which would be lots easier if I could automate it. Doesn’t sound possible though.

Why programs need to ask you if you want to quit is beyond me.. I clicked the bloody X of course I want to quit!

There's definitely a solution. I did something similar 20+ years ago in Visual Basic (simulate keystrokes to accomplish some kind of system task, can't even remember what now though). Dead easy, just like programming a macro really. Does VB even exist any more? Sure you could do something similar in VC++ or whatever. Will involve coding a (very simple) app which may be more involved than you want.

Obviously these days I'd just create an action in Automator which would take about 10s 🙂

TBH, I'd be seeking alternative software which was fit for purpose. If this behaviour is intentional then surely everyone using it would have the same dilemma

I thought you worked in IT 😀 - Virtually every cock-a-meany development house has its own WTAF?? requirements once it escapes into production. I have a few running on platforms disowned by the manufacturer (Oracle PE take a bow) that the message 'if this burns, I cannot help you' seems to go unheard. It's always fixed in the next version, in 6 months, in a year....

Solution...

[img] [/img]

So this application only does it's update when it closes? And only when it closes gracefully, which requires user interaction? If so, utter garbage - get it in the bin post haste.

However, you can send key presses with SendKeys. Not ideal, but just Google wscript.wshell and SendKeys. You will have to write a script in your language of choice to do this (I would use Powershell, but that's just me).

So this application only does it's update when it closes? And only when it closes gracefully, which requires user interaction?

Logically then, the update process may be a separate program which launches on exit. So you could potentially force close the main app and then run the updater manually. Have a look in TaskMan when the update is running?

If so, utter garbage - get it in the bin post haste.

My sentiments exactly. I find it hard to believe that production software would behave in this manner without someone complaining about it / fixing it.

The other consideration I suppose though is, is it actually safe to force close? It sounds like the sort of software that would eat its own database for giggles.

OP can try CloseMainWindow() in his script.

The other consideration I suppose though is, is it actually safe to force close? It sounds like the sort of software that would eat its own database for giggles.

You have no idea how true this is, and it’s par for the course in this trade. After the program lunches itself, data corruption is then a chargeable repair by the software company, even though it’s their shitty software. Been here before.

That’s actually the main reason I’m trying to do this, because what happens is if the proper procedures aren’t followed then it ends up taking ages to load in the morning when someone wants to use it. Then they decide to force close it and try again, not had any problems yet with this software but previous experience dictates that mashing the X when the loading bar isn’t going fast enough doesn’t end well...

Sendkeys was my first thought but it a. Requires a script, currently I’m just using the taskkill on a scheduled task. And b. I think just fires the key press to the command prompt it opens?

Another vote for AutoIT. I got it doing stuff exactly like that about 5 years ago. Worth learning the basics.

Why are you still using it? It's not fit for purpose, **** it off.

I needed to procrastinate this morning, so:
[code]
#Let's get the nasty app
$victim = get-process [i]process_name_of_rubbish_app[/i]

#Bring the window into focus
[void] [System.Reflection.Assembly]::LoadWithPartialName("'Microsoft.VisualBasic")
[Microsoft.VisualBasic.Interaction]::AppActivate($victim.id)

#Perform a virtual Alt+F4
$victim.CloseMainWindow()

#Send 'enter' key
[void][System.Reflection.Assembly]::LoadWithPartialName("'System.Windows.Forms")
[System.Windows.Forms.SendKeys]::SendWait('~');
[/Code]

Stick that in a .ps1 file, changing the process name as required, then set up a scheduled task

The path to the program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argument list as: -NoProfile -NonInteractive -ExecutionPolicy Bypass -command c:\[i]path_to_script[/i]

I have made some assumptions here, but provided you are not on XP it's a good start.

Standard disclaimer - use this at your own risk, adapt as necessary.

The other consideration I suppose though is, is it actually safe to force close?

why ?

Because if you force close it then the program is not being notified that it is closing, it is just being terminated by the OS.

So therefore to be safe you, as a program, must never cache anything, unless you use a robust journalling system to help you recover anything corrupted by being abruptly terminated - like word for example tries to do with corrupted files.