Writing program to handle extra mouse functions

[archcommus]

I have a Logitech MX510 and Vista. As you may know Logitech never released MouseWare for Vista. Would it be possible for me to write my own program to detect and handle events for the extra buttons on my mouse? I know C, Java, etc. Might even be able to do some x86 assembly if required.

Thanks.

 

[Markbnj]

You would basically have to write a program to open the mouse as a USB device and then communicate with it as the Logitech driver would. You can find plenty of information on enumerating and communicating with USB devices. Just Google "USB programming." But the tricky part would be figuring out the messages that the mouse uses to communicate with Mouseware. I'm sure it could be done. Google "Logitech USB protocol" and you'll find some people have already poked around and figured some stuff out.

 

[DaveSimmons]

Whatever drivers are running might still be sending the windows messages for the extra buttons, you could try setting a mouse hook to see.

Google "SetWindowsHookEx WH_MOUSE WM_NCXBUTTONDBLCLK WM_NCRBUTTONDBLCLK"

 

[Markbnj]

True. The side button on my G5 works without logitech software running. But the scroll wheel side-to-side does not.

 

[QuixoticOne]

I thought that Microsoft (stupidly, as usual) made it basically 'impossible' (besides a very restricted set of options) to add in a user-supplied filter driver / main driver / filtering application for the system's Mouse or Keyboard.

I think the idea was to avoid spyware.exe from hooking your keyboard and mouse and then recording you logging in to your bank or from injecting arbitrary command sequences into your system as keyboard / mouse input when you're not around / looking / controlling the process.

Obviously such rootkit-ware / spyware does EXIST and function on many MS OS variants, though I'm not sure if it basically has to patch / hack the system in undesirable / exploitive type ways to get that functionality to work in modern MS OSes.

To be clear, your application can RECEIVE system keyboard / mouse input when YOUR APPLICATION has input focus, but it can't (IIRC) hook / intercept / filter that input when your application DOESN'T have input focus. So basically it just gets an already filtered / processed copy of the data event messages WHEN the system decides it has focus, and it ISN'T hooking them at a system level. Obviously you can do whatever ACTIONS you want with the data WHEN you have input focus, but you can't in general send those "I have a new keyboard input / mouse input" messages BACK into the system for other applications to transparently/unknowingly use as keyboard/mouse input events.

I believe they have some kinds of device driver code signing / WHQL type requirements in some OSes (XP?, Vista?, maybe Win2k?) so that you can't even install your own device driver / filter code for a device that will be the system keyboard / mouse, you can only use the Microsoft originated or MS approved codes.

I THINK that's why (AFAIK) a lot of the keyboards and mouse devices that have "extra control" buttons actually appear as MULTIPLE USB HID devices, one device that's just a "basic" KB / MOUSE, and the OTHER device that just sends events corresponding to those "extra" buttons to do things like PREVIOUS, NEXT, BACK, RELOAD, MEDIA PLAYER, SLEEP, whatever. Then it's easier for 3rd parties (like Creative Labs or maybe YOU) to write control utility applications that intercept events on those extra button events without their application having focus at the time. However I think there may be a limited set / number / schema for those extra "keycodes" or whatever, so I'm not sure how easy it would be to do totally arbitrary things with them. Anyway the problem STILL exists that though your application CAN intercept those EXTRA HID input message codes for the AUXILIARY buttons NOT logically part of the SYSTEM MOUSE/KEYBOARD, you STILL cannot (easily/theoretically) take those button events and use them as MACROs to GENERATE SYSTEM INPUT MESSAGES that ACT LIKE Keyboard/Mouse input for OTHER applications which is IMHO one of the MAIN desirable uses for MACRO buttons in the first place.

so i.e. it'd be hard to bind the 5th mouse side button to send the keyboard input sequence ALT+F+P to the running application (e.g. to PRINT shortcut/macro for MS Office or whatever) when you hit that mouse button.

Though you could have your OWN program intercept that input and do something IT ITSELF can do / launch without involving the system KB/MOUSE data streams.

 

[archcommus]

Hmm, got real busy this weekend but these are all good ideas I'll look into, thanks!

 

[Neverm1nd]

Originally posted by: QuixoticOne
I thought that Microsoft (stupidly, as usual) made it basically 'impossible' (besides a very restricted set of options) to add in a user-supplied filter driver / main driver / filtering application for the system's Mouse or Keyboard.

I think the idea was to avoid spyware.exe from hooking your keyboard and mouse and then recording you logging in to your bank or from injecting arbitrary command sequences into your system as keyboard / mouse input when you're not around / looking / controlling the process.

Obviously such rootkit-ware / spyware does EXIST and function on many MS OS variants, though I'm not sure if it basically has to patch / hack the system in undesirable / exploitive type ways to get that functionality to work in modern MS OSes.

To be clear, your application can RECEIVE system keyboard / mouse input when YOUR APPLICATION has input focus, but it can't (IIRC) hook / intercept / filter that input when your application DOESN'T have input focus. So basically it just gets an already filtered / processed copy of the data event messages WHEN the system decides it has focus, and it ISN'T hooking them at a system level. Obviously you can do whatever ACTIONS you want with the data WHEN you have input focus, but you can't in general send those "I have a new keyboard input / mouse input" messages BACK into the system for other applications to transparently/unknowingly use as keyboard/mouse input events.

I believe they have some kinds of device driver code signing / WHQL type requirements in some OSes (XP?, Vista?, maybe Win2k?) so that you can't even install your own device driver / filter code for a device that will be the system keyboard / mouse, you can only use the Microsoft originated or MS approved codes.

I THINK that's why (AFAIK) a lot of the keyboards and mouse devices that have "extra control" buttons actually appear as MULTIPLE USB HID devices, one device that's just a "basic" KB / MOUSE, and the OTHER device that just sends events corresponding to those "extra" buttons to do things like PREVIOUS, NEXT, BACK, RELOAD, MEDIA PLAYER, SLEEP, whatever. Then it's easier for 3rd parties (like Creative Labs or maybe YOU) to write control utility applications that intercept events on those extra button events without their application having focus at the time. However I think there may be a limited set / number / schema for those extra "keycodes" or whatever, so I'm not sure how easy it would be to do totally arbitrary things with them. Anyway the problem STILL exists that though your application CAN intercept those EXTRA HID input message codes for the AUXILIARY buttons NOT logically part of the SYSTEM MOUSE/KEYBOARD, you STILL cannot (easily/theoretically) take those button events and use them as MACROs to GENERATE SYSTEM INPUT MESSAGES that ACT LIKE Keyboard/Mouse input for OTHER applications which is IMHO one of the MAIN desirable uses for MACRO buttons in the first place.

so i.e. it'd be hard to bind the 5th mouse side button to send the keyboard input sequence ALT+F+P to the running application (e.g. to PRINT shortcut/macro for MS Office or whatever) when you hit that mouse button.

Though you could have your OWN program intercept that input and do something IT ITSELF can do / launch without involving the system KB/MOUSE data streams.

Very litte of this is in fact true.

You can create an app to run in the background or from the tray and intercept all keyboard and mouse events before they're sent to the app with focus, with SetWindowsHookEx like DaveSimmons suggested.

I don't really know about mice, but keyboards will usually send the OEM_KEY keycodes for 'special' buttons, no drivers needed. You could intercept these messages and map them to actions in your program. I assume that you can do the same with the mouse keys.

You can transmitt keyboard events via sendkeys, and there's probarbly a similiar interface for the mouse.

I'm doing this on Vista right now, and it works just fine.

 

[archcommus]

Originally posted by: Neverm1nd

Originally posted by: QuixoticOne
I thought that Microsoft (stupidly, as usual) made it basically 'impossible' (besides a very restricted set of options) to add in a user-supplied filter driver / main driver / filtering application for the system's Mouse or Keyboard.

I think the idea was to avoid spyware.exe from hooking your keyboard and mouse and then recording you logging in to your bank or from injecting arbitrary command sequences into your system as keyboard / mouse input when you're not around / looking / controlling the process.

Obviously such rootkit-ware / spyware does EXIST and function on many MS OS variants, though I'm not sure if it basically has to patch / hack the system in undesirable / exploitive type ways to get that functionality to work in modern MS OSes.

To be clear, your application can RECEIVE system keyboard / mouse input when YOUR APPLICATION has input focus, but it can't (IIRC) hook / intercept / filter that input when your application DOESN'T have input focus. So basically it just gets an already filtered / processed copy of the data event messages WHEN the system decides it has focus, and it ISN'T hooking them at a system level. Obviously you can do whatever ACTIONS you want with the data WHEN you have input focus, but you can't in general send those "I have a new keyboard input / mouse input" messages BACK into the system for other applications to transparently/unknowingly use as keyboard/mouse input events.

I believe they have some kinds of device driver code signing / WHQL type requirements in some OSes (XP?, Vista?, maybe Win2k?) so that you can't even install your own device driver / filter code for a device that will be the system keyboard / mouse, you can only use the Microsoft originated or MS approved codes.

I THINK that's why (AFAIK) a lot of the keyboards and mouse devices that have "extra control" buttons actually appear as MULTIPLE USB HID devices, one device that's just a "basic" KB / MOUSE, and the OTHER device that just sends events corresponding to those "extra" buttons to do things like PREVIOUS, NEXT, BACK, RELOAD, MEDIA PLAYER, SLEEP, whatever. Then it's easier for 3rd parties (like Creative Labs or maybe YOU) to write control utility applications that intercept events on those extra button events without their application having focus at the time. However I think there may be a limited set / number / schema for those extra "keycodes" or whatever, so I'm not sure how easy it would be to do totally arbitrary things with them. Anyway the problem STILL exists that though your application CAN intercept those EXTRA HID input message codes for the AUXILIARY buttons NOT logically part of the SYSTEM MOUSE/KEYBOARD, you STILL cannot (easily/theoretically) take those button events and use them as MACROs to GENERATE SYSTEM INPUT MESSAGES that ACT LIKE Keyboard/Mouse input for OTHER applications which is IMHO one of the MAIN desirable uses for MACRO buttons in the first place.

so i.e. it'd be hard to bind the 5th mouse side button to send the keyboard input sequence ALT+F+P to the running application (e.g. to PRINT shortcut/macro for MS Office or whatever) when you hit that mouse button.

Though you could have your OWN program intercept that input and do something IT ITSELF can do / launch without involving the system KB/MOUSE data streams.

Very litte of this is in fact true.

You can create an app to run in the background or from the tray and intercept all keyboard and mouse events before they're sent to the app with focus, with SetWindowsHookEx like DaveSimmons suggested.

I don't really know about mice, but keyboards will usually send the OEM_KEY keycodes for 'special' buttons, no drivers needed. You could intercept these messages and map them to actions in your program. I assume that you can do the same with the mouse keys.

You can transmitt keyboard events via sendkeys, and there's probarbly a similiar interface for the mouse.

I'm doing this on Vista right now, and it works just fine.

You're using SendKeys now? How, via VBScript? I tried that awhile ago for something else but wasn't entirely satisfied with it. Namely, every time I used it it turned off NumLock. So instead I tried AutoIt script with its own version of send keys and it worked very well.

Anyway, thanks, hopefully there is a similar interface like that for the mouse.

 

[Neverm1nd]

Sorry, I got it mixed up. The method's called SendInput, you can use it both for mouse and keyboard

 

[archcommus]

Originally posted by: Neverm1nd
Sorry, I got it mixed up. The method's called SendInput, you can use it both for mouse and keyboard

Thanks.