Client should have a new flag for enabling the interception of keyboard inputs as they're typed as an argument of a client proc as they would appear in a text input box, so we can make our own custom text input boxes.
For example, client.capture_input = TRUE will cause all typeable characters typed to be passed to client.CaptureInput(char), as the characters would be typed, with the correct capitalization according to Shift/Caps Lock, and with symbols as they should be according to the user's keyboard layout, etc.
As in, totally not what the Any macro does. I guess this may be an alternative replacement argument like [[*]].
ID:2491888
 Aug 1 2019, 8:20 pm
|
|||||||
| |||||||
|
Aug 1 2019, 10:40 pm
|
|
Lummox JR
   |
Responsiveness would be terrible. Seems like a better solution would be to have on-change that could send the text, and maybe offer some control over (and reading of) selection.
|
That sounds better. I totally forgot about using a hidden Input control, typing into that and (periodically) reading its text out to a HUD element. Next steps would be to improve that.
Given that we can't really tell where the mouse is relative to the text, selecting maptext with the mouse seems far off (but... would be nice). Cursor key selection (or with arbitrary macros) seems much more doable. Maybe have a maptext_cursor position variable, defaults to null for not visible, works based on standard text positions (1 for left of the first character, etc.), draws an (optionally-)blinking caret (or a highlight or underline of the character at that position) at that position instead of it being in the HUD or in the maptext itself. In addition to maptext_cursor, text selection would require another cursor position as a selection start, which would "highlight" the maptext between the positions. CSS-wise, the text cursor should support caret-color, and the text selection highlight should support the ::selection pseudo-element. | |