Cheat Engine

[hyphen]

It seems to me that all these coding languages read top to bottom in order. That means you can only have one thing going on at once.

Well, I'm wondering, what if say, you made some basic console app. And you wanted to implement a check for the hotkey "ESC" at all times. When ESC is pressed, the application closes down (if... goto or w/e).

Assuming there are plenty of pauses and user prompts in the application, if you wanted the check for ESC to always be there, you would have to place code for it after every single instruction....

And if you wanted the application to constantly check for 10 other key combinations as well, you would have to add 10 more checks after every single instruction.

What do you do then? There has to be a way, considering how most programs these days are loaded with hotkeys/shortcut keys.

And I hope your solution doesn't involve running an application that monitors keypresses and acts on another application X.X

Feel free anyone to share your opinion. If there is actually a very simple solution............

[Dark Byte]

That's called threading
In windows (and most unix systems) applications can have 1 or more threads running at the same time.

You can spawn a new thread that runs in the same application but with it's own registers, but with direct access to the same memory as the original thread (main thread). I know, it might sound like a different app that has memory control over the original app, but it's a bit more complex than that.

Now in that other thread you can do a constant loop that checks the keystate, and if a key is pressed act on it.
Acting on something can be complex to implement though. You could just handle it directly from inside the thread that does the constant polling(if no gui interaction or notification is required), or you could dispatch the event to the mainthread so it handles it next time it checks the message que, or spawn of a new thread that does what you want.
Just modifying memory that is used by another thread is a risk, since the other thread might not expect you're changing it. Especially memory allocation, or more precisely freeing, can cause nice crashes when another thread is reading a buffer and the other one decides to free it. To fix this, you can make use of locks (mutex, critical section, multi read exclusive write locks, etc...) so that when your thread is going to write, you first acquire the lock for the specified block, write, and release, so other threads can make use of it.

Keep in mind that even though threads share the same memory, you might want to tell your compiler that certain memory might be modified by other threads. It depends on the language, bit with C you can usually handle this by adding the word volatile in front of it.

e.g:

[NoManchesPuto]

[Jani]

Also you might want to read about event driven programming. You shouldn't use N threads to do N stuffs(checks or sth) concurrent, instead you should be using events.