Updated June 2021, see History
Tab(-1,158) must be followed by "C", and then a coded byte indicating the number of lead-in bytes to be sent with each mouse action, followed by the lead-in bytes. The coded byte should be chr(32+number of lead-in bytes). For example, the ESP package uses the following to enable mouse cursor reporting:
PRINT TAB(-1,158); "C"; CHR$(34); CHR$(27); CHR$(30)
This causes the two lead-in bytes, CHR$(27) and CHR$(30) to be sent at the start of each mouse event. These are followed by one byte indicating the row (coded as CHR$(31+row) followed by one or two more bytes indicating the column (from the same table), and finally a status code: CHR$(32) = sequence terminated; CHR$(33) = right button pressed; CHR$(34) = left button pressed; CHR$(35) = middle button pressed.
A single click will generate two sets of the above sequences, the first ending with the status code indicating the button (corresponding to the down click) and the second ending with the termination status code (corresponding to the up click). A double click will generate three sets of the above sequences, with the last two both ending with the termination status (as if it were one down click followed by two up clicks). Consequently, you would probably need to use a timed input routine, such as TINKEYxs or GETKEY to determine whether the last part of the sequence was present.
Additional information may be found in the discussions on Mouse Interaction and MX_MCRS.
History
2021 June, A-Shell 6.5.1704: The TAB(-1,158) scheme for converting mouse clicks into byte sequences now works with controls that are nested within parent controls, such as a TABX or dialog.
