I know this is OT but we seemed to have collected some XP guys here
Is there a way to associate an input device to a particular window?
In this case I would like to keep a numeric pad associated to my MP3 player while I am using the mouse on other aps.
Hi g,
Windows and Linux guys.
Do you mean your 10 key pad to the right of your keyboard? Then no, it is just an input device and the "Active" (or "in focus") window has dibs
To have exclusive rights, you need a specialty drivers that send directly to your desired app. And, you may have, depending on what you are doing.
-T
I was thinking about a separate USB connected key pad but I suppose it is the same deal. If the window is not the "active" one, none of the input devices seem to want to work. I just was not sure there was not a way to associate a device to a window.
You can have two mice, each of which will work at (almost?) the same time, but only one cursor, so I don't think that does you too much good.
(You can have two keyboards too, both of which can type at almost the same time, but unless you stop and go to another field, I think they will type into the same field.)
Can you now have a numeric pad that will control your MP3 player at all and how does that work?
There's an XP newsgroup where they know many xp things. microsoft.public.windowsxp.general
I use an old DOS player that has been upgraded to run under XP (MPXPLAY) it takes a numeric input to run like a jukebox I can run it from a modified Seeburg 3W1
BTW I have never bumped up against a limit on the number of USB mice and keyboards.
There are 4 keyboards of one type or another on this machine. the 3W1 plugs into the PS/2 port There is full function keyboard for maintenance and I have 2 numeric pads scattered around. (2 monitors, 2 amps)
snipped-for-privacy@aol.com posted for all of us...
And I know how to SNIP
Just as a cautionary note; the current available is limited by the m/b manufacturer. If you have some heavy draw items and things get flaky that is why. Most users never experience this.
Such a thing could be programmed easily enough at an elemental level but I've never heard of it being done.
To do so - in your case - one would check to see from whence the input was coming; if not from the external keypad, the input would be passed through; if from the external keypad, one would then check to see if your MP3 player had focus...if yes, the key pad input would be passed through; if not, it would be ignored.
I'd just like to rub it in a little. Things like this are done all the time with Linux desktops. It's trivial.
With my limited adventures in Windows land, it always seems like there's a straight jacket around the whole mess. Maybe to keep the inmates from hurting themselves.
Let's not be so smug in your geekiness...or we'll put you on "Big Bang Theory"! ;^)
Can't stand that show. Yes I'm a little geeky, no I don't act like that. I've never known anyone that acts like that.
Hi Dan,
Try the I.T. Crowd. It is English. Here is a short clip:
Although, I do believe they are making fun of us I.T. folks, although I am not sure how.
:-)
-T
Papa Microsoft know best :)
Never heard of it before. I'll have to see if I can find it and get it on my DVR.
I've known so many different kinds of people in IT over the years, it's hard to make generalizations. Lots of them are even good at home repair.
Thanks!
+1
| >> I was thinking about a separate USB connected key pad but | >> I suppose it is the same deal. | >> If the window is not the "active" one, none of the input | >> devices seem to want to work. I just was not sure there | >> was not a way to associate a device to a window. | > | > Such a thing could be programmed easily enough at an elemental level but | > I've never heard of it being done. | > | > To do so - in your case - one would check to see from whence the input was | > coming; if not from the external keypad, the input would be passed through; | > if from the external keypad, one would then check to see if your MP3 player | > had focus...if yes, the key pad input would be passed through; if not, it | > would be ignored. | | I'd just like to rub it in a little. | Things like this are done all the time with Linux desktops. | It's trivial. |
?? If you have a minute while your Linux miracle washes the dishes and vacuums the rugs, I'd be curious to know how that works. :)
You know of settings to direct any input device to any process? So you could plug in 3 keyboards and direct them all to different running programs? And you could also block each from reaching any but the intended window? And in this process the active window doesn't change? I don't see how that's possible unless the software in question is itself designed to monitor the port and can identify the desired source, while the system accepts only one input source for the active window. On Windows the system sends the input messages to the active window. I don't see how that would be different on Linux, unless there's some sort of total, universal hook that listens in on everything and provides user-level settings to direct any input to any process, all without changing the active window. It's hard to even think of any normal situation where such functionality would be relevant.
This should work:
Use the method described for separate languages to assign unique keysyms to one of the keyboards. Then Bob's your uncle.
There are probably lots of other methods. Just the first search hit I got.
| > You know of settings to direct any input device to | > any process? | | This should work: | |
That link has nothing to do with sending input to a non-active window.
As I said, that gets you as far as generating unique keysyms. Then you can configure the window manager to react to those unique keysyms. I thought that would be enough for you to figure out the rest.
In the case of Linux music players, it's pretty easy to interact with them without generating input for the window, for example, here's my config for Fvwm/xmms2:
DestroyFunc Xmms2 AddToFunc Xmms2
(Control Pause toggles playing. Shift and left/right on the keypad change volume, shift and the mouse scroll wheel also changes volume.)
I have similar configuration for xmms, Audacious, and rhythmbox.
It's just as simple to tell the WM to select a window and generate synthetic keystrokes if the player doesn't already have a command interface. Of course selecting a window with the WM will make the window active, you'll have to first capture the active window and switch back.
I know I start windows on other virtual pages, without switching to the window/page by setting the style "SkipMapping" on them. I think the same technique works for sending keystrokes, I've never tried it, because I don't need it.
| here's my config for Fvwm/xmms2: | | DestroyFunc Xmms2 | AddToFunc Xmms2 | + I Exec exec xmms2-launcher | + I Exec exec xmms2 playlist shuffle | + I Exec exec xmms2 playlist play | + I Silent Key KP_Right A S Exec xmms2 server volume +2 | + I Silent Key KP_Left A S Exec xmms2 server volume -2 | + I Silent Mouse 4 A S Exec xmms2 server volume +2 | + I Silent Mouse 5 A S Exec xmms2 server volume -2 | + I Silent Key Pause A C Exec xmms2 toggle |
It never ceases to amaze me that Linux people will think it's impressive to say things like: "Hey, I can do that with 27 lines in a console window. You poor Windoze people have to click a button or something." Since 1995, few people will be impressed that you can control a music player without using a UI of any kind. They'll be even less impressed that they can write excessively bloated and abstruse config entries for custom commands. You may find it hard to believe, but that just isn't a compelling salespitch.
(Not to mention the only-geeks-could-love-it naming traditions. Anything named Fvwm/xmms2 has no right to exist. :)
| It's just as simple to tell the WM to select a window | and generate synthetic keystrokes if the player doesn't | already have a command interface. | Of course selecting a window with the WM will make the | window active, you'll have to first capture the active | window and switch back. |
Yes. The whole point was to send messages to windows that are not active, without changing the active window. He doesn't have any problems with sending his commands, as I read it. He just wants to send them to a non-active window. I don't know of any way to do that, and if you could it would require both a specific OS functionality and a target process that's designed to listen somehow. The system sends input to the active window. So it seems the target process would need to be hooking into all input, like a sort of super keylogger, since its window is not receiving the input. The target software would have to be designed for that purpose in the first place and would have to provide config options for it. Once that's solved, you'd need to figure out how *not* to send the specific input to the active window. That would mean having something like a Control Panel applet that lets you configure details of which processes can receive input from which devices. (Or on Linux, of course, it would require that someone online has posted 53 lines of interminable gobbledygook that you can enter into a console window to accomplish the same thing.)
Maybe all of that exists and is possible on your Linux Miracle, but I don't see how. ...But at least you don't have to use a chisel and a stone tablet, so I guess Linux may not be far, now, from being ready for prime time. :)
I'm no expert to that level on Win or Linux, but I think one very important difference is that Linux is an open source OS, while Windows is not. From what I know, you could change anything you want on Linux, including changes to the OS code itself. So, I see how you could do it with Linux. The part I have doubts about is the claim that it is trivial. Trivial to me in the context here means that they typical user could do it through the normal settings, etc. I have doubts about that too.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.