Enter should not insert a line break in editable text

When a cell is set to “Editable in Prototype”, I would expect that ENTER should simply confirm the text entry and leave the cell whereas RETURN should insert a line break.

1 Like

I’d like to second this.

It would also be nice if the text was selected when I click into the cell in a prototype. In most cases the text I write in AT is a placeholder text for an input field or a search bar and the user is supposed to input something. The way it works right now, the text needs to be selected/deleted manually by the user which is rarely the intended behavior (at least for the cases I tried to use this feature).

Me too. I tried this on left-click but it is not working. Needs a little help I think :slight_smile:

let element = targetCells[0].DOMElement;

let textSpan = element.querySelector("span > span");

a little bit longer, but maybe something like this one:

select text.zip (180.8 KB)

In Firefox/Chrome this selects the text on click (or while tab into the text cell), on safari a click places the cursor (which is in line with the normal Mac behavior).

1 Like

Brilliant. Thanks. Problem solved!

Just to clarify: the original problem is not solved. The script allowed for the auto-selection of text on click, which is nice but enter should still not insert a line break when entering text.

1 Like

Should something happen when hitting enter or should it simply be ignored?

It should confirm the entry and place the caret at the end, I guess.

I guess that somewhat depends on the situation. Most input fields just lose focus after the user hits enter (a search for example executes the search after hitting enter but usually doesn’t remain editable). In a Form I would probably want to make the next input field editable after I input a value. Maybe the default behavior could be be as Stephan suggested, but the interactions could get a “editable in prototype” action? For Example:

On Key Down/Up
“Group selected by user”
-Set to editable in prototype

I guess that would be quite a bit more effort to implement than simply fixing the original line break issue though.

For the “Return/Enter”-case I currently don’t see a simple workaround. You can register for an Keyboard event which is called when return/enter is pressed (see Key Down/Up Event in our documentation). But:

  • these are handled globally (that is, even though the event handler is added to a certain cell, it is called every time the Return/Enter is used
  • AFAIK differentiate between Return and Enter key would require a small script (event.location == DOM_KEY_LOCATION_NUMPAD means Enter is used (a normal “Return” would use KeyboardEvent.DOM_KEY_LOCATION_STANDARD, see KeyboardEvent for the glory details)).

One thing which is often a good choice is to use an HTML input type=“text”-tag instead of our “Editable in Prototype”. This way the behaviour to select all on focus in etc. are working out of the box. And it is easy to get notified when the text changes, you can give autocomplete and whole bunch of other stuff.

Absolutely. But that does not allow me to double-click the text in the prototype to change it.

yeah, it really should be integrated into Antetype. We briefly discussed it internally, “Editable in prototype” has the big advantage of the seamless integration into the rest of Antetype (styling etc.).

Yes, and it is not just convenience. I am developing a hefty prototype for crossplattform software design and I expect that this might be rolled out one day to be used by more team members. The more I have to explain (“no, you cannot use the text box because it does not play nice with ENTER”), the more complicated an adoption will become.