Tell cursor position in a TextField?

[ywangd]

It seems not possible to tell where the cursor is at in a TextField? For TextView, there is the selected_range property. But it is not available for TextField.

[briarfox]

@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.

[ywangd]

@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 ...

[JonB]

You can use a one line textview instead. Also... Did you try selected_range? I vaguely recall some undoc'd methods that worked.

[ywangd]

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_return method (for stash to decide whether a command is ready to be executed) and it is only available to TextField.

[omz]

@ywangd You could emulate textfield_should_return with textview_should_change and check for a newline ('\n') there...

[ywangd]

@omz Thanks! That's a great idea. Still need to emulate the clear button etc. But it now seems to be doable.

[ywangd]

@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!

[JonB]

I have a few wacky ideas on this.

1. TextView inside of a scrollview.

textview_did_change_selection or textview_should_change would use 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_offset to 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_string each 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).
Then, your textview_should_change simply grabs selected_range[1], multiplies by the character width, and then adjusts the offset to leave a certain amount of gap.

2. You could instead use an HTML input field controlled with javascript inside a WebView. This has the advantage of being very customizable, but the disadvantage of being javascript, and debugging javascript within pythonista is akin to trying to program using only a typewriter.

3. I've been long considering trying to create a fully custom ui.View that acts similar to a textfield. touch_began would 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.