CreateTextEntry with > basic ascii support possible?

1

It appears that IEditableTextControl (CreateTextEntry) can only handle the basic ascii character set as it uses WDL_String which, AFAIK, only handles integers from 0-127 (basic ascii).

Is there any way to extend the functionality of this control to handle a greater range of input characters like 0-255 (extended ascii) or even UTF8 - or would this require a completely new set of functions?

2

The text entry does support more than basic ascii, but they key handling is not supporting it it seems (trying on macOS). You can paste unicode text there, but you can’t type in unicode characters. This would be some work to fix

2 Likes
3

Thank you for the reply.

Yes, when I enter any character above code #127 (even by pasting) Text Entry returns a negative number - as I would expect with the “char” data type (it overflows into twos complement/negative numbers). It seems a change to “unsigned char” might be do-able but I don’t know all the ramifications. “WDL_String” looks pretty complicated to modify. Will take a look.

4

WDL_String doesn’t need to be modified. WDL_String should store UTF8 anyway, but i am not sure which WDL_String you are referring to.

Could you try something and see if it behaves how you expect with this modification:

change line 846 to

  NSString* s = [pEvent characters];

This still doesn’t allow me to type multi character sequences on the macOS keyboard, in order to type accented characters, but its a start

5

Thank you for the reply and the suggestion. I will give this a try on Mac later today (I’m currently on Win10) however it seems the range restriction starts right at the beginning with this step from IEditableTextControl:

  void OnTextEntryCompletion(const char* str, int valIdx) override
  {
    SetStr(str);
    SetDirty(true);
  }

If I check the contents of “str” after entering any character above code 127 the character captured in str is corrupt. I believe that is because str is a char data type, i.e., it can only hold 0-127 (the basic ascii set) - whereby it works fine.

6

UTF8 uses multiple char to encode the characters, Instead of 16 or 32 bit numbers

1 Like
7

Thank you for that info. I do see now that some characters entered create a second character in the string - and neither are the input character. I will have to study this a bit and find out how to parse the string in that case.