Daniel F wrote:
hmm, according to that site, sendinput just may be exactly what i need
to send input to a directinput-using app. I will give it a shot and
let know how it goes. i'm curious why pywin32 doesnt wrap sendinput,
among other functions? any specific reason, or "just didnt get to it
yet" ?
SendInput is "relatively" new. It was first introduced in NT Service Pack 4, and it isn't the kind of API that comes up very often.
but a question still remains - what do i do in order to capture
messages before they get to the app? As you remember, i need to
capture the keystrokes first, then generate them on another machine. Whin i use pyHook (wrapping setwindowhookex), and hook keystrokes
while ff7 is in the foreground (not even doing anything else - just
hooking and releasing, or hooking and blocking), ff7 gets screwed up
somehow... seems to get the keystrokes in triplicate about 90% of the
time. So i need a way to capture the keystrokes too - if not capture
then at least read, without screwing up the local-running ff7. any
ideas?
I don't know the answer to this. Games tend to be straight-to-the-metal applications: they don't truck with a lot of filtering and intermediate DLLs. You might be able to use the debug APIs to watch for the loading of the DirectInput DLL and insert some manual hooks, but that's a pretty high level of guruness. Google for "api dll injection".
also, regarding the use of scancodes... looks like python win32 doesnt
wrap MapVirtualKey (to convert form vk to scancode) either. i suppose
ctypes should help me out with this one, too?
ctypes is a wonderful package -- invaluable for someone doing Win32 API work. Basically, it allows you to call any API in any DLL, as long as you can describe the parameters.
Well then... thanks for warning me off that path before i ventured down it. :) Though i wonder if i could find an existing kernel filter driver and put it to work for me. they must be out there somewhere, no..? but i will try playing with ctypes and sendinput first.
There are some HID filter drivers in the DDK supplied by Microsoft. As a general rule, it is rare to find a publicly-available third-party kernel driver. There are several reasons for that. Most drivers are written for a specific device, and are not useful in the general case. Device-specific drivers often include information that the manufacturer considers to be proprietary. The support burden for a kernel driver is much greater than a user-mode app. And, the investment in creating and debugging a driver is so high, that most manufacturers don't want to help the competition by providing the labor for free.
-- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc.
_______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
