Visual Hilighting Bug in Unity GUI

Other controls are hilighted by the mouse when you're dragging an active control (e.g. scrollbar).

If you run the code below and start dragging the slider and the mouse goes over a button, the button will (incorrectly) hilite.

Code (csharp):

1. var guiSkin : GUISkin;
2. var confirmationMessage : String = "Are you really sure you want to do that? I'm not sure it's such a great idea.";
3.  
4. private var windowRect : Rect;
5. private var s : float = 50;
6.  
7. function Start() {
8.     windowRect = Rect (Screen.width - 340, Screen.height - 140, 320, 120);
9. }
10.  
11. function OnGUI () {
12.     GUI.skin = guiSkin;
13.     windowRect = GUI.Window (0, windowRect, WinConfirm, "Confirmation");
14. }
15.  
16. function WinConfirm (windowID : int) {
17.     GUI.Label (Rect (10, 20, 300, 60), confirmationMessage);
18.    
19.     // Make the first button. If it is pressed, Application.Loadlevel (1) will be executed
20.     if (GUI.Button (Rect (140,90,80,20), "Cancel")) {
21.         print( "Cancel" );
22.     }
23.  
24.     // Make the second button.
25.     if (GUI.Button (Rect (230,90,80,20), "OK")) {
26.         print( "OK" );
27.     }
28.    
29.     s = GUI.HorizontalSlider( Rect(10,60,300,10), s, 0, 100 );
30.    
31.     // Make window draggable
32.     GUI.DragWindow (Rect (0,0, 10000, 20));
33. }

 

The edit field doesn't support the clipboard. I know that's kind of obscure, but it's very useful (especially for folks entering long license codes...)

Also, by default, on a Mac, text fields start with their content selected. This also appears to be the new "standard" in Vista (at long last).

Also, if I do this:

Code (csharp):

1. GUI.SetNextControlName("EditField");
2. t = GUI.TextField(Rect(10,60,300,20), t);
3. GUI.FocusControl("EditField");

I get the very worst kind of text field behavior (i.e. the Windows 3.x default) which is the text caret at the start of the text field.

At minimum it would be nice to be able to find out the current selection within an TextField and change it.

 

I think most of these fixes will be rolled up into an upcoming Update.

 

If I click in a text field on a Mac, it just places the cursor, whereas tabbing to it selects all.

Is this the same on Vista?

 

I'm talking about (a) tabbing (or using Focus), or (b) when a dialog first appears and gives you focus on the first field.

The clicking behavior is OK (and so is double and triple -clicking) -- but kind of irrelevant.

 

I have that problem too - i don't know of a way to control the 'highlighting' of a textfield.

Ideally the Focus script function or TAB key should highlight the entire contents of a textfield, and move the caret to the initial position in a textarea.

 

I'm not sure about text areas ... probably moving to the end of the text in the area would be the best option ...

 

The focus behaviours are fixed in the next release. Thanks for your feedback.

TextFields get all selected when you tab or call SetForcusControl, TextAreas get cursor at beginning (Mac - behaviour).

 

Nicholas, I'm using the password masking script you gave us before and when I double click to highlight the password, everything but the first character gets selected. Triple clicking highlights the whole lot.
Any ideas?

Thanks
Shaun

 

Not of the top of my head - can I get you to file a repo case?

 

Nicholas, I just submitted the case - haven't had an email about it. Issues are below, just in case the report went to the cyberdump.

1) Provide a summary of the issue:
GUI Highlighting Inconsistency


2) Steps to Reproduce: Detail the steps taken to produce the bug.

Problem 1: Double clicking on the password field highlights all but the first character

Problem 2: Highlighting the username and then tabbing doesn't keep the 'highlight mode' for the password

Inconsistency: Highlighting any number of characters in the password field keeps the highlight mode when Tabbing to the username field.

Problem 3: Under VISTA, the Tab action actually adds the TAB character to the text or password field

Problem 4: Under VISTA, even after setting the 'hot' control, it still requires two Tabs to move to the next field. There's also some weirdness highlighting in Vista, but I'm not able to test it here

Problem 5: If the OSX Input type is set to any stroke based language (CJK), Unity doesn't respond to the input (generally apps just display a box in place of the char if the font doesn't exist, but it usually does if you can select the input method, which is another problem entirely) To reproduce, try enabling Korean Hangul 2-Set Input mode and type anything into a Unity textbox.