Tell cursor position in a TextField?
It seems not possible to tell where the cursor is at in a TextField? For TextView, there is the
selected_rangeproperty. But it is not available for TextField.
@ywangd I didn't quite do it with TextField but by letting pyte from stash's ssh handle it, I'm able to to type at the cursor location on screen.
@briarfox I am asking this question for a different feature, the virtual key buttons for symbols.
If no way to tell the cursor position, the symbol just has to be inserted at the end of the line ...
You can use a one line textview instead. Also... Did you try
selected_range? I vaguely recall some undoc'd methods that worked.
I asked this question before the new year and completely forgot about it till just now ...
@JonB TextField does not support
selected_range. Any other hidden functions you may know?
I thought about using one-line TextView to emulate TextField. But I really need the
textfield_should_returnmethod (for stash to decide whether a command is ready to be executed) and it is only available to TextField.
@ywangd You could emulate
textview_should_changeand check for a newline (
@omz Thanks! That's a great idea. Still need to emulate the clear button etc. But it now seems to be doable.
@omz I am having difficulties to enforce a single line for TextView.
The problem is that TextView automatically wraps a line if it is longer than the view's width. This behaviour effectively makes the single line appear as two lines visually.
I can set the TextView's width large enough so that a long string can fit visually as a single line. But this causes another issue. The TextView does NOT (automatically) scroll horizontally. So texts outside of the right bound of the TextView is invisible.
Any help is appreciated!
I have a few wacky ideas on this.
- TextView inside of a scrollview.
ui.measure_string(which has to be inside a drawing context as i recall) to figure out the width of text before the cursor, and then would adjust the scrollview's
content_offsetto keep the cursor on screen.
My initial thought was to compute this on the fly, which might be insanely slow, since you'd be calling
measure_stringeach and every keystroke, but I've been surprised at the speed of the built in drawing functions. Also, since you're using a monospace font, just compute the character width once during startup (maybe compute the average character width for a string containing all of the alpha numeric, uppercase, punctuation that are typical, so that even proportional fonts would be approximately correct).
selected_range, multiplies by the character width, and then adjusts the offset to leave a certain amount of gap.
I've been long considering trying to create a fully custom ui.View that acts similar to a textfield.
touch_beganwould focus a hidden textview, to accept keystrokes and in particular backspaces. This would require implementing customized timers to implement gestures for the ui events (long tap to bring up a copy/paste dialog, double tap to select words, dragging selection boundaries, etc). The deal breaker would probably be that as soon as you touch anywhere, the keyboard might try to disappear, thinking input has ended.