I'm looking for a way to shutdown a windows app from another. Is there a way to do this?
Ideally I'd like something that basically mimics an ALT-F4, or pressing the 'X' in the top right corner or some such.
Alternatively, is there an application out there that does this already? tskill is a bit too harsh for what I have in mind.
EDIT: I did a little digging and found a MSDN Article with the Microsoft recommended approach.
Since this is a windows app you can send the WM_CLOSE message to the main window however keep in mind that if the application overrides handling of the WM_CLOSE message you may get unexpected results. Also keep in mind that use of win32 functions like TerminateProcess and ExitProcess can also have unpleasant side-effects (see the remarks sections on msdn) including global data in dll's getting compromised as well as deadlocks.
If you are responsible for having coded the target application I would recommend adding some form of built in termination mechanism that can be triggered externally (e.g. magic packet on the loopback address or pipes) that way you can be sure your application has cleaned up after itself appropriately.
According to your description this sounds like a windowed app. In that case you can send it a WM_CLOSE message to mimic the behavior when pressing the "X" button.
Another alternative is to use TerminateProcess, but this is probably what tskill does as well.
More powerful command to close app is:
PostMessage (myhnd,WM_ENDSESSION,TRUE,ENDSESSION_LOGOFF);
I'll first refer you to my answer to another question; although it was about Delphi and services, the answer is neither Delphi- nor service-specific. In short, there is no generic way to gracefully stop a program. The accepted answer for that question demonstrates posting a wm_Close message to a program's window.
Related
Well the title seems pretty clear about what I want to do.
More precisely: I want to create a program (c++ or java is preferred) that manipulates the mouse in two ways, like: changing its position and doing clicks.
I was thinking about using allegro (it has mouse routines to manipulate the things cited above) or sdl(which I don't know if has that kind of routine). I tried with allegro nsuccessfully. My problem here was that I couldn`t virtually "do" clicks. I also couldn't redirect the stuff changed by my program to some other window.
Any tips?
There are a couple of ways to try automating other applications on Windows...
At the simplest level, one can use PostMessage to post keyboard and mouse messages to another application's windows. This has the advantage that it could work even if the other application is minimized. Unfortunately, this approach skips the majority of the input processing logic so applications that directly access key state using GetAsyncKeyState will not see (for example) the control key being 'down' no matter how many WM_KEYDOWN, vk=VK_CONTROL messages you send.
As Hans Passant commented, SendImput places input events in a lower level input event queue, and so can fully simulate modifier keys. These input events are not posted to windows however, so to get the input events delivered successfully the normal windows rules of activation and focus need to be followed. That said, this is the approach used by most testing-automation software (and is why most testing automation software requires the application being tested be the active application).
The last of the automation methods Ill mention - and sadly the least likley to work - is the Microsoft UI Automation framework. This framework is intended to allow applications to be used by disabled and/or special needs users. Sadly - very few software providers bother to implement this API in their products.
We have an old legacy app that we need to reverse engineer how it works. (The documentation has gone missing.) Our application is communicating with a 3rd party program using windows messages (WM_xxx).
So first attempt is to start spy++ and look at what messages are sent when certain events occur.
We notice that most events are WM_USER+1025 and similar.
So currently we are planning to start writing down what each WM_USER-message should be. It would be great if we could add that information to spy++ to get more readable data the more work we put in.
It is possible to write some "add-on" to spy++ to tell it how to interpret WM_USER+1025?
(Similar to the CustomEvaluators you could write to the VS6-debugger.)
Regards
Leif
After some more thinking, and reading Pat Brenners post on spy++ internals I realize that it would be darn near impossible to write such a "custom display formater".
spy++ injects a dll into each monitored process. When a WM_msg is sent or received a hook in the injected dll detects this and passes this information on to the main spy++-process.
To write a custom evaluator that would have to be present in the injected dll (or sucked in from that dll). Which can cause complications normally desired to avoid.
I'll just do it the "normal" way, of modifying my source code.
/L
I wish to build my own application which can send keyboard commands(messages) to the Windows OS.
For example when I press the combination ctrl+shift+n, I wish to launch the notepad.exe . How can I do that? Do you have some advice for me about the concept used.
I've read that is possible when are used keyboard hooks? That's the only way? Do you know a free and open-source application which does this as simple is possible?
Your particular example can be done without any programming at all, by right clicking on Notepad, selecting Properties, and setting the "hot key" (various Windows versions might call it by a different name) to Ctrl+Shift+N.
If you still would like to write a program to do this, have a look at the RegisterHotKey Win32 API function.
AutoHotkey is a free, open-source utility for Windows.
You can automate many tasks with the above utility, check it out.
Things to bear in mind:
A system-wide keyboard hook requires the writing of a DLL. There's example keyboard hook code on my website here.
Hooks cannot be installed from a low to a high integrity level application in Vista and Windows 7/8/10. So there's no guarantee your hook will work, depending upon what the foreground application is when the key gets hit.
As Greg pointed out, a lot of the time, RegisterHotKey is a much simpler solution for this problem.
Using VB6
At the time of executing, it showing white blank screen while it was working with database,
How to avoid the white blank screen in VB6.
WHITE BLANK SCREEN MEANS HANGING (WHEN IT WAS WORKING WITH DATABASE).
How to avoid that?
I assume you mean that the GUI won't redraw itself when executing a long-running operation. (Shouldn't actually be that visible starting with Vista, but I digress).
If your long-running operation is composed of several steps or tight loops, then you can sprinkle a call to DoEvents every once in a while to cause the form to remain somewhat responsive even when doing work.
Another option would be to migrate your long-running work into a separate thread but last I looked this wasn't exactly trivial or easily possible in VB6.
You should work with data base in separate thread, and any time-consuming operation should be run in a separate thread too. In this case your user interface won't be frozen.
I posted this as an answer to another question, but the pattern applies here as well:
VB6, on its own, is single threaded. However, you can make it somewhat multithreaded via the use of ActiveX EXE that run in their own process, yet still are tethered to the original VB6-created EXE.
What I've used in the past is the Timer object in conjunction with an ActiveX EXE. This approach will give you an ability to localize all the downloading logic in one place, control it like you control a regular object and have it run in a separate EXE, thus by default making it multi-threaded.
So the way this works is like so:
You call the LongRunningOperation method on the ActiveX EXE object
In the LongRunningOperation method, you instantiate the Timer and have it kick off almost immediately.
You get out of the LongRunningOperation method, thus giving control back to the entity that called it.
Then you communicate back to the main app via Events (e.g. LongRunningOperationProgress or LongRunningOperationComplete, etc...)
I recommend the Timer object from Karl Petersen.
This is actually the same problem as your "How to exit the program immediately" question. In both cases, the problem is that your database operation is blocking the VB6 program from executing.
The answer you accepted for the other question - use ADO to carry out the operations asynchronously - will also solve this blank screen problem.
Or if you prefer, follow one of my suggestions in my answer to your other question and use a .NET background worker component through Interop like this.
Or follow my other suggestion and delegate the database work to an ActiveX exe like this. EDIT AngryHacker's nice answer to this question uses this method.
Your first instinct should be to put your resource-intensive operations in a separate thread. This is a bit difficult in VB6, although possible (but not recommended) if you invoke the native CreateThread API.
You can also migrate to VB.NET, and use Thread objects natively.
I'm a bit rusty on my Windows system programming...
Is it possible for a program to send a keystroke (I'm guessing by SendMessage() api call) to another application, if the (open) target application does not currently have the focus? If it is possible, does it then make the target application become the active application, or does it still remain in the background?
Thanks in advance for any info you may be able to provide!
No, It will not change the focus, unless subsequent calls do setfocus. It will remain the same window order
PostMessage(hwndOther, WM_KEYDOWN, VK_ENTER, 0);
This works for me, but only under Windows XP.
But On Vista and Windows 7 I've too got problem. Propably with UIPI.
I am trying to send a message to process from a DLL injected to this process.
How to fix it?
From memory: Yes, No.
You are looking for WM_KEYDOWN:
PostMessage(hwndOther, WM_KEYDOWN, VK_ENTER, 0);
For a directed send of keystrokes, SendInput is the native method of choice, though it is subject to UIPI (integrity level) checks on Vista/2008/W7. You can't send keystrokes to an app that has an IL > yours.
A more general solution for capturing and redirecting input is a global keyboard hook (See the help for SetWindowsHookEx). But this is fairly hairy stuff - you have to cope with how you send the keystrokes on, you affect every process in the system because your code is effectively inserted in the input stream, it involves writing a native DLL... you have to know exactly what you're doing.
We use a global keyboard hook in our system (I wrote it), but we're a special case - a single function emergency call handling system. I wouldn't advise a global hook as a solution in general purpose Windows computing.
You don't need SendInput() or hooks
The answer with PostMessage is wrong.
You must attach remotely your thread. See on Win32 api Group where it's a very classic question (C code, right MS method)
Yes you can send keystrokes, no it won't bring the other window to the top.
One way is to use the SendInput API function - here's an example of how to use it in VB6 (ulp!).
Probably easier to use GUI Automation which is supported directly from .NET Framework 3.0 - for instance read this.