UIInput bugs in 3.0.8f3

[ryan]

If I open and run the Tutorial 9 scene from the examples, click the input and type in some characters, then use the left arrow key multiple times to move the carat back, it only moves one character before getting stuck.  It looks like it's actually adding some invisible characters to the string, as I see some odd artifacts in the inspector which also become visible in the game window if I switch to a dynamic font.

Possibly related, when running in the editor on Mac, cmd-x/cmd-c/cmd-v to cut/copy/paste are also inserting an x, c, or v character.  This only happens in the editor, not when building and running the app, so I consider it a minor issue.  I ran into this a while back with a separate product, and I think it was actually a unity problem where the editor wasn't reporting events properly when the command key was involved, but maybe there's something you can do about that.

[ArenMook]

Sounds like a Unity issue, yeah. It certainly doesn't happen on Windows.

[dbuck]

I'm seeing the same here in osx with a dynamic Helvetica font, I just worked around with my own validator that is a bit more strict than .none.

The other issue I'm seeing is that for multiline labels, I cannot click to select the caret position or click/drag to select chars from the lower lines

Selecting: http://screencast.com/t/yy5BTHRYZ
Arrow keys while using the default validation: http://screencast.com/t/OY5G8VPDJa2y

There also seems to be something about having to click twice to select text sometimes, but not always.

[ArenMook]

Re: selecting -- I'm guessing you didn't update the collider size.

Re: arrow keys -- likely yet another Unity bug that I'll need to work around on OSX.

[dbuck]

Oh damn. yep, that was it! .ResizeColliders onChange clears that up.

one other other minor extremely edge case:
the caret falls behind the end of the text as it starts to wrap, 1 char per line if you are typing a large string with no spaces. new char's are placed correctly, the caret just show's in the wrong spot since it takes into account the \n's added from wrapping.

I also tend to think that on OSX Command-Return to submit and Return for newline feels nicer when changed to Return for submit, and Shift-Return for newline

overall a HELL of a lot nicer than the previous setup!

[ArenMook]

Aside from the caret, the characters from arrow keys and such only happen in OSX editor, right? Not at run-time?

[dbuck]

I am seeing the strange chars in the osx build when set to Validation.None

[ArenMook]

I'll add it to the list of fixes in f4 (eta tomorrow)

[ArenMook]

Oh yes to update this one... I can't repro it on my Macbook. Neither Editor nor stand-alone builds exhibit any issues in Unity 4.3. Arrow keys, backspace, everything works as expected.

[BFSKyle]

For the Arrow Keys, a simple work around is to filter out the arrow keys in the input string.

I managed to get arrows working properly again by changing UIInput.cs line 515 from:

1. if (ch >= ' ') Insert(ch.ToString());

To:

1. if (ch >= ' ' && ch != 63234 && ch != 63235) Insert(ch.ToString());

That fixed it up for me. This was only tested on my Mac, so not sure if it has any side effects on Windows.

[schneidb]

Hi guys,

BFSKyle: Thanks for the workaround.  I'm seeing this issue as well (MacBook Pro OS X Mavericks, Unity 4.3.4f1, NGUI 3.5.2 (haven't yet updated to 3.5.3, but I don't see this issue addressed in the release notes and because Aren said he couldn't reproduce above, I assume it isn't being addressed.

Aren: If I implement BFSKyle's workaround, I assume I'm going to have to re-apply it with each NGUI update (standard license, not pro).  Is this correct?

[ArenMook]

I'd add that change if I knew what those magic numbers were in order to better understand what effect this would have on other platforms. What's 63234 and 63235? Where were they derived from? I can't find any info on that.

[schneidb]

Hi Aren,

Ok, here's what we get...

If the up arrow is pressed, we get Unicode character U+700, which in UTF-16 (decimal), is 63,232.
If the down arrow is pressed, we get Unicode character U+701, which in UTF-16 (decimal), is 63,233.
If the left arrow is pressed, we get Unicode character U+702, which in UTF-16 (decimal), is 63,234.
If the right arrow is pressed, we get Unicode character U+703, which in UTF-16 (decimal), is 63,235.

So ideally, we would ignore all of these for input and use them only for moving the cursor.  On the Mac, the standard is that pressing the up arrow key should put the cursor in front (to the left) of the first character, pressing the down arrow key should put the cursor behind (to the right) of the last character, pressing the left arrow key would move the cursor one position to the left and pressing the right arrow key would move the cursor one position to the right.

[ArenMook]

Alright, how about this one?

1.                         if (string.IsNullOrEmpty(ime) && !string.IsNullOrEmpty(Input.inputString))
2.                         {
3.                                 // Process input ignoring non-printable characters as they are not consistent.
4.                                 // Windows has them, OSX may not. They get handled inside OnGUI() instead.
5.                                 string s = Input.inputString;
6.  
7.                                 for (int i = 0; i < s.Length; ++i)
8.                                 {
9.                                         char ch = s[i];
10.                                         if (ch < ' ') continue;
11.  
12.                                         // OSX inserts these characters for arrow keys
13.                                         if (ch == '\u0700') continue;
14.                                         if (ch == '\u0701') continue;
15.                                         if (ch == '\u0702') continue;
16.                                         if (ch == '\u0703') continue;
17.  
18.                                         Insert(ch.ToString());
19.                                 }
20.                         }

[schneidb]

That doesn't work, but this does...

1.                         if (string.IsNullOrEmpty(ime) && !string.IsNullOrEmpty(Input.inputString))
2.                         {
3.                                 // Process input ignoring non-printable characters as they are not consistent.
4.                                 // Windows has them, OSX may not. They get handled inside OnGUI() instead.
5.                                 string s = Input.inputString;
6.  
7.                                 for (int i = 0; i < s.Length; ++i)
8.                                 {
9.                                         char ch = s[i];
10.                                         if (ch >= ' ' && ch < 63232 && ch > 63235) Insert(ch.ToString());
11.                                 }
12.                         }
13.