Hi Thomas, > I have a (normal) two button mouse and want to change the behaviour > of a mouse button to act as if I pressed the »CONTROL« key on the > keyboard.
> Use case: A DOS application where the mouse acts as a pointer without > the need to click. This suggests to use the mouse buttons for > productivity, e.g. assign the CONTROL key to the mouse. I remember that Logitech mice for DOS had a tool where you could "type" pre-recorded text snippets by clicking the mouse while it was not used, so I guess your idea to simulate control being held as long as the right mouse button is held has some similarity. Which leads to the question: Are there freeware TSR floating around which already provide what you need? I guess it is a bit uncommon that your app does use the pointer but not the buttons. In any case, I think it is better to use a separate tool for what you want instead of adding it as a feature to cutemouse. Let me sketch the idea... Not necessarily for you, but for people pondering to write a TSR for this :-) Install check 1: check if int 33h vector is not null Install check 2: int 33h, ax=0 check if ax=-1 returned Check buttons: int 33h, ax=3, returns bx, cx and dx, right button is second lowest bit of bx. Callback for buttons: int 33h, ax=0ch, cx=18h, es:dx pointer to far call to be invoked on right button press/release. Call will receive ax=flags (10h for release, 08h for press) bx=buttons cx,dx=location, si,di=movement. More modern callback: alternatively use int 33h, ax=18h to register a far call (cx=0 to unregister in theory and cx=18h, es:dx null in reality) Either way, you probably are at risk to collide with other apps also registering callbacks if you use those. If you use function 3 to check buttons, you will have to set a timer event to do that at regular intervals and make sure to not do it while the mouse driver is already busy with something else. You probably also want to trigger only while a cursor is visible or while the driver is enabled. For that, you would intercept int 33h and check for ax=1fh/20h (disable/enable driver), ax=1/2 show/hide cursor etc. If it is only relevant to modify the state of keyboard "control" in context of mouse activity itself, you can intercept int 33h calls such that if your app looks at the mouse status, you "look over it's shoulder" and use the right mouse button status to update keyb "control". Your app might look at the status of the "control" key by calling int 16h, ah=2, which returns al bit 2 set if control is pressed. So you could intercept that and set bit 2 yourself based on mouse status, which you can poll at that moment using int 33h, ax=3. On more modern keyb, the call would be int 16h, ah=12h or, rarely, 22h. Both let you set extra flags in ah: bit 0 for left and bit 2 for right control key, among others. An even easier way to manipulate the apparent status of "control" is to set bit 2 at 40h:17h or, if you also want to manipulate left and right control, bit 0/2 at 40h:18h. The difference is: If your app calls int 16h to check for control, you can catch the calls as just the right moment to check mouse buttons. In that case, you probably want to avoid callbacks. If it does NOT, you probably want to either use the mouse callback OR a timer event to get a trigger when the mouse button changes and use that to set the appropriate 40h:... bit, from where on the keyboard driver will take care of the rest, in most situations. If your app actually uses low level I/O to the keyboard controller, things would get a lot more ugly, because you would have to tell the hardware to fake keypresses. Even in DOS, I would say that this is relatively rare :-) Programmatically messing with keyboard input was sort of popular in the old days, so I think it is quite possible that a TSR which does EXACTLY what you want already is out there and somebody here knows one :-) I remember to have used a TSR which worked the other direction, moving the "mouse" pointer with the keyboard, too. In case nobody knows a suitable TSR for you, we would have to play around with the ideas mentioned above, to make something which does not interfere too much with normal mouse usage of your app. Several methods possible. I hope somebody can suggest a nice pre-existing TSR :-) Regards, Eric PS: There is no need to buy a "programmable" mouse. The difference is just a more "programmable" driver, which probably is not provided for DOS in modern gaming mice. So I recommend standard mouse + driver + a special TSR. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
