Artificial Keypresses

SendMessage with a WM_CHAR message?

(you didn't comment whether that answer satisfied you or not in your other thread)

Yes it did, its good to know that TSR type programs can be achieved simpy and not so complex like it was with DOS.

Thanks

So, you know anything about the artificial keypress issue?

Quote:

Original post by SelethD Yes it did, its good to know that TSR type programs can be achieved simpy and not so complex like it was with DOS. Thanks So, you know anything about the artificial keypress issue?

Yes, if you follow the two links my post contains, they'll point you to the functions you probably need to implement that.

looks like someone is going to make a bot!!??

@ O.P.: You may not get much help with what you want.

Consider an app that could

1) Obtain a handle to a current internet browser.
2) Find the HWND to the address bar (not difficult, once you
have the app's handle)
3) enter your website's URL and enter...

That's pretty slick, but also immensely annoying adware and no disciplined programmer is likely to give you the keys to that bomb factory.

Anyone dumb enough to run that type of app (or download something that would install it) may deserve what s/he gets, however...

So... sorry you're not getting the roadmap. (you'll probably find it eventually)

That may be true, but you cant hold back knowledge for a legitimate application just because some idiot wants to screw things up.

Im trying to make a little application that can take in data from a LPT port that is connected to my own custom joysticks, arcade contorl panels, and driving wheels that I have made myself, and convert the data from these devices into keypresses that way even if a game is made only to recieve keypresses from the keyboard, I can still use my custom game controls. because the game thinks it is getting keypresses from the keyboard

so i see i need to use SendMessageCallback, and send the current applicaiton WM_CHAR messages, but how do you get the handle to the current application?

Does anyone have any source code examples or tutorials on somthing like this?

Try EnumDesktopWindows, FindWindowEx and related functions as a starting point.

thanks for all the advice, ill play with these and see what I come up with.

I'm pretty sure SendMessage won't work. If you're targeting Windows 98+ (meaning you're excluding 95), you can use SendInput. Otherwise, you'll have to use keybd_event for keyboard events and mouse_event for mouse events.

To get the foreground application, use GetForegroundWindow, and then use GetWindowLongPtr with the GWLP_HINSTANCE argument to get the HINSTANCE of the program that owns the window.

A lot of games uses DirectInput, which, afaik, works on a lower level and I don't think it would care about SendInput and mouse_event and such.

Those games are probably not relying on key and mouse messages, but are using DirectX to read the state of the mouse and keyboard.

Possibly the only way to work around this without resorting to hardware would be to do something down at the driver level, but that's definitely outside my realm of knowledge.

Right. For those apps, you'll need to write your own keyboard driver (or joystick driver). Have fun.

Yeah about the DirectInput stuff. I made a JScript to send specific key combos about 50 times a second to play a joke on my friend, and foudn that I could only manipulate the menus in the game. Anyway, in JScript, you would use the SendKeys method of the WScript.Shell object to send keys.

I'm not sure if it will help much, but SysInternals.com provides the source for a keyboard driver (Ctrl2Cap) that they describe as "a kernel-mode device driver that filters the system's keyboard class driver in order to convert caps-lock characters into control characters."
Perhaps it will guide you on the way to device-driver creation.

Ill check out that site and see where it leads me. Ive been brushing up on assembly, I kinda feel that I might have to use it. Any good tutorials on modern 32bit assemby? All I can find is the old 16 bit that doesnt support protected mode I probably need something along the 80386 or higher assembly code.

Thanks

Ok, I think im getting confused. I cant quite get a clear idea of the flow of data from the keyboard to an application.

Does anyone know the correct flow? Keyboard -> Buffer -> Windows -> etc, somting like that?

I here about the keyboard BIOS, and the keyboard Interrupt, and a keyboard Buffer.

Are these one in the same, or different, or do they even exist under a modern windows OS? So much of what I read seems to pertain to DOS so I dont know what is what.

And how does a keyboard driver fit into the picture?

Interrupts still exist on modern OSes (I think), but you'll never be messing with them. The BIOS is just where a lot of build-in code lies.

I THINK the order is:
Keyboard -> Interrupt -> Driver -> Windows -> Hooks -> Message Pump

Each and every stage might be buffered, and AFAIK there is no single important one.

I need to know what is the earliest stage that a program can add input into a buffer as though it was from the keyboard itself.

There just isnt enough information on this type of thing, or else its just extreamly hard to find :)

I think the driver converts the scan codes into data and places this in a buffer, perhaps if I knew how to access the buffer that a driver accesses, I could slip in my own data?

Ill keep looking