This program draws "radar like" circles around the mouse pointer if a hot
key combination is pressed, to locate the position of the mouse pointer
easely. Another function of this program is to toggle screens, again on
a configurable key combination. The program works with precisely zero
system patches and a clean and safe implementation.
_____________________________________________________________________________
Synopsis:
MarkMouse MARKKEY,TOGGLEKEY
MARKKEY A keyboard - mouse button sequence that launches
the radar mouse ping. Defaults to the sequence
"LCommand RCommand"
TOGGLEKEY A keyboard mouse sequence to toggle screens.
Defaults to "LCommand ,"
_____________________________________________________________________________
About the keyboard sequences:
A keyboard mouse sequence is a list of sequences of keyboard - mouse button
combinations that must be pressed to invoke the selected program function.
More than one sequence can be given as alternative options, separated by
a vertical bar "|".
A sequence is build on single key presses, each separated by an
ampersand "&" sign. Each key press consists of a list of keyboard
qualifiers which is optionally - like the shift or alt keys - and the key-
board key itself, which can be left blank.
Syntactically,
keyboard_mouse_button_sequence := sequence [ | sequence [ | sequence...]]]
sequence := keypress [ & keypress [ & keypress...]]]
keypress := [qualifier [qualifier...]] [key]
where square brackets [] indicate optional arguments.
_____________________________________________________________________________
To give some examples:
"LCommand ," The left Amiga key (Commodore on some keyboards)
pressed together with the comma key. Only one
keyboard press.
"LShift LButton" The left shift button with the left mouse button.
"LButton & RButton" A two-key keyboard sequence. To invoke it, the
left mouse button must be pressed first, then the
right mouse button must be pressed, in this
order. Note that "&" implies a time order!
"LButton | RButton" Either the left button, or the right button.
"LHold RButton" The right button must be pressed while the left
button is hold down. Note that the left button
press is not swalloed by MarkMouse, but the right
press is.
"LHold RButton | RHold LButton"
Either hold the left button and press the right, or
hold the right button and press the left.
"LAlt n & RShift m" A two-key keyboard sequence. First, the left alt
key must be pressed with the "n" key, then the
right shift key must be pressed with the "m" key.
Note that the characters are given in lower case,
failing to do so will imply an additional "LShift"
qualifier.
"MButton & Num 2" The middle mouse button, followed by the "2" key on
the numeric key pad. Note that the keys must be
pressed in THIS order, mouse button first, keyboard
key later.
"Num 2 & MButton" The "2" key on the numeric keyboard, followed by
the middle mouse button. Note that is different
from the sequence above as the keys must be pressed
in the opposide order.
"Num 2 | MButton" Either the numeric key on the numeric keyboard, or
the middle mouse button.
"MHold l" The "l" key on the keyboard while the middle mouse
button is pressed. The middle mouse button press
leaks thru to the system, the "l" key pressed after-
wards not. Pressing "l" alone *is* of course reported
to the system and ignored by MarkMouse.
"MHold l | MHold r" The "l" key while the middle mouse button is held
down, or the "r" key on the keyboard while the same
button is held. Note that there's no kind of
"bracketing".
_____________________________________________________________________________
The full list of qualifiers:
LShift the left shift key
RShift the right shift key
Ctrl the control key
LAlt the left alt key
RAlt the right alt key
LCommand the left Amiga (or Commodore) key
LAmiga a synonym for LCommand
Commodore again, the same key
RCommand the right Amiga key
RAmiga just the same key
Amiga again, the right amiga key
Num the key is meant to be a key on the numeric pad
LHold the left mouse button must be held down
MHold same for the middle button
RHold same for the right button.
_____________________________________________________________________________
Special key names:
Note that you may always specify an "ordinary" key by the (lower case) letter
printed on the key:
LButton a left mouse button press
MButton a middle mouse button press (if available)
RButton a right mouse button press
BackSpace the backspace key
Tab the tabulator
Enter the "Enter" key on the numeric keypad, must be
specified as "Num Enter"
Return the "Return" key on the main keyboard
Esc the escape key in the upper left corner
Del the delete key above the cursor keys
Up the cursor-up key
Down the cursor-down key
Left the cursor-left key
Right the cursor-right key
F1..F10 the function keys
All other keys just by what the current (default) keymap says.
_____________________________________________________________________________
Credits:
Thanks to Werner Müller for testing this program.
_____________________________________________________________________________
Implementation specific details:
The program does *not* install any patches to do what it wants to do. It
differs in that point to many other "commodities" I've seen that try to
do something similar. It is still safe to use, if not safer than those
hacks that patch your system.
However, this has its price: The mouse pointer will become very "sluggish"
if the "radar waves" are engaged. This is because the graphics is (and has
to be) drawn by the input.device input handler. This was done because the
current implementation of intuition swaps the screens in terms of the
same handler, therefore the "FrontScreen" screen pointer in the intuition
library is, at that point, always valid. Other implemenations would either
call LockIBase() - which causes the same side effects of locking the mouse
pointer for the same reason - or would start a patch-attack by patching
every single intuition function that could possibly invalidate this pointer.
It was felt that the current implementation - even though it depends on
intuition internals - is the most robust solution to this problem.
The screen toggle function was, in the same spirit, not implemented by
calling any "ScreenToFront()" system function. Locking the intuition with
LockIBase() will cause a dead-lock if ScreenToFront() is called, and on
the other hand *not* calling LockIBase() might result in passing an invalid
pointer back to the ScreenToFront() system function. Note that many programs
ignore this risk, even the CBM "FKey" commodity just "calls the function
and runs", hoping that nothing bad could possibly happen. The current
implementation inserts a "LCommand m" keyboard sequence into the input
device handler chain, hence letting the intuition input handler doing the
dirty work for us. Note that this is again implemenation specific, but the
most safest way I could think of.
I personally haven't been able to crash MarkMouse yet...
_____________________________________________________________________________
The THOR-Software Licence (v2, 24th June 1998)
This License applies to the computer programs known as "MarkMouse". The
"Program", below, refers to such program. The "Archive" refers to the
package of distribution, as prepared by the author of the Program,
Thomas Richter. Each licensee is addressed as "you".
The Program and the data in the archive are freely distributable
under the restrictions stated below, but are also Copyright (c)
Thomas Richter.
Distribution of the Program, the Archive and the data in the Archive by a
commercial organization without written permission from the author to any
third party is prohibited if any payment is made in connection with such
distribution, whether directly (as in payment for a copy of the Program) or
indirectly (as in payment for some service related to the Program, or
payment for some product or service that includes a copy of the Program
"without charge"; these are only examples, and not an exhaustive enumeration
of prohibited activities).
However, the following methods of distribution
involving payment shall not in and of themselves be a violation of this
restriction:
(i) Posting the Program on a public access information storage and
retrieval service for which a fee is received for retrieving information
(such as an on-line service), provided that the fee is not
content-dependent (i.e., the fee would be the same for retrieving the same
volume of information consisting of random data).
(ii) Distributing the Program on a CD-ROM, provided that
a) the Archive is reproduced entirely and verbatim on such CD-ROM, including
especially this licence agreement;
b) the CD-ROM is made available to the public for a nominal fee only,
c) a copy of the CD is made available to the author for free except for
shipment costs, and
d) provided further that all information on such CD-ROM is redistributable
for non-commercial purposes without charge.
Redistribution of a modified version of the Archive, the Program or the
contents of the Archive is prohibited in any way, by any organization,
regardless whether commercial or non-commercial. Everything must be kept
together, in original and unmodified form.
Limitations.
THE PROGRAM IS PROVIDED TO YOU "AS IS", WITHOUT WARRANTY. THERE IS NO
WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE THE PROGRAM, THE ARCHIVE
AND ALL DATA OF THIS ARCHIVE FROM YOUR STORAGE SYSTEM. YOU ACCEPT THIS
LICENCE BY USING OR REDISTRIBUTING THE PROGRAM.
Thomas Richter
_____________________________________________________________________________
Thomas,
March 1999
|
aminet net>