Tasharen Entertainment Forum

Support => NGUI 3 Support => Topic started by: ryan on December 31, 2013, 04:15:34 PM

Title: UIInput bugs in 3.0.8f3
Post by: ryan on December 31, 2013, 04:15:34 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on December 31, 2013, 04:19:42 PM
Sounds like a Unity issue, yeah. It certainly doesn't happen on Windows.
Title: Re: UIInput bugs in 3.0.8f3
Post by: dbuck on January 01, 2014, 10:30:58 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on January 01, 2014, 10:36:49 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: dbuck on January 01, 2014, 11:49:35 PM
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!
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on January 02, 2014, 12:17:54 AM
Aside from the caret, the characters from arrow keys and such only happen in OSX editor, right? Not at run-time?
Title: Re: UIInput bugs in 3.0.8f3
Post by: dbuck on January 02, 2014, 11:08:18 AM
I am seeing the strange chars in the osx build when set to Validation.None
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on January 02, 2014, 11:12:06 AM
I'll add it to the list of fixes in f4 (eta tomorrow)
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on January 04, 2014, 10:52:14 AM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: BFSKyle on February 19, 2014, 11:17:23 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 07, 2014, 05:45:20 PM
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?
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on March 08, 2014, 12:51:37 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 08, 2014, 04:19:44 PM
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.
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on March 09, 2014, 09:25:37 AM
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.                         }
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 10, 2014, 09:44:53 AM
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.  
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 10, 2014, 09:54:14 AM
I should also clarify, that this also works to solve the problem we've been discussing...
  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 == 63232) continue;
  14.                                         if (ch == 63233) continue;
  15.                                         if (ch == 63234) continue;
  16.                                         if (ch == 63235) continue;
  17.                                        
  18.                                         Insert(ch.ToString());
  19.                                 }
  20.                         }
  21.  

... but there is another problem that is only an issue in the editor that the first solution (from my previous post) also addresses.  That issue is that you can use Command+p on the keyboard to play and stop in the editor.  If you are in play mode in the editor while an NGUI UIInput field has focus, the 'p' part of Command+p is inserted into the field.
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 10, 2014, 04:02:48 PM
I apologize, it would appear I'm being an idiot today as the code I proposed actually blocks all input.  This does work, however...
  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 != 63233 && ch != 63234 && ch != 63235) Insert(ch.ToString());
  11.                                 }
  12.                         }
  13.  

Sorry about that.
Title: Re: UIInput bugs in 3.0.8f3
Post by: ArenMook on March 10, 2014, 08:31:36 PM
I don't see any difference between your last two functions logic-wise. The only difference is one does an equality check and the other does an inequality check.

Thinking about it, my code should have been using '\uF700' etc, as that's the correct hexadecimal representation.
  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 == '\uF700') continue;
  14.                                         if (ch == '\uF701') continue;
  15.                                         if (ch == '\uF702') continue;
  16.                                         if (ch == '\uF703') continue;
  17.  
  18.                                         Insert(ch.ToString());
  19.                                 }
  20.                         }
Title: Re: UIInput bugs in 3.0.8f3
Post by: schneidb on March 11, 2014, 04:42:02 AM
Yes, this does indeed work.  It doesn't address the command+p issue I described, but that is an Editor only issue that I can live with.  Thanks!