Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - indiefreaks

Pages: 1 [2]
16
No need to reply, I just spent the required time to read through the forum and the product detail page on this same website ;)

Thanks

17
Hmmm, I didn't know about this option... Is there a way for me to upgrade to this version? What would be the additional cost if possible?...

18
NGUI 3 Support / Re: UIInput gameobjects do not receive OnKey event
« on: February 12, 2013, 11:41:24 AM »
Great! I'm pleased to see that it made it through ;)

Btw, these are the best 100€ I spent on the store so far: great job with it ;)

19
I don't know if I have the pro edition...  ???
I did pay for the NGUI version on the Asset Store thow ;)

20
NGUI 3 Support / Re: UIInput gameobjects do not receive OnKey event
« on: February 12, 2013, 10:34:23 AM »
So maybe the UIInput isn't actually generic enough. UIInput could be use for simple username and password fields in a form thus requiring Button Key Bindings (for standard keyboard navigation functionnality) or for a chat input too.

What would you recommend? Should I create my own textbox specific UIInput scripts to handle form "like" behaviors and use NGUI's UIInput script for other more text intensive inputs?
Or would you consider specializing these scripts in the future to handle both scenarions therefore mimicing the Windows controls differentiation between a "Textbox" and a "TextArea"?

Thanks

21
I understand such requirement especially for mobile devices.

I can live with a local implementation but what would be your best advice and recommendation to create my own custom controls while keeping the benefits of your code?

Inheritance isn't a viable option as you do not expose any virtual implementation on the processing of text for either UIInput or UILabel.
The sole way I can see would be to copy/paste your UIInput and UILabel scripts and make my changes to it and then use a Diff tool each release you make to apply your own fixes and features to them.

Thanks

22
NGUI 3 Support / Re: UIInput gameobjects do not receive OnKey event
« on: February 12, 2013, 10:13:17 AM »
I'm sorry, I actually typed it wrong: I did meant to say Button Keys and not Button Key Bindings.

When a UIInput is placed on a gameobject, no other attached script will receive the OnKey event because of this test you make on the UICamera.Update() method that I mentionned in my previous post.

You can verify it by yourself adding a Button Keys script to an Input gameobject or even simpler adding a custom MonoBehaviour class with a simple Debug.Log() call in a void OnKey(KeyCode key) method implementation.

I removed the test for the inputHasFocus boolean set in the code above the ProcessOthers() method call and it still run fine. What was the purpose of such test?

Thanks

23
NGUI 3 Support / UIInput gameobjects do not receive OnKey event
« on: February 12, 2013, 07:45:46 AM »
Hi,

I noticed that UIInput gameobjects don't receive OnKey events when the focus is set on them preventing us from using ButtonKeyBindings to create forms which support keyboard tab and shift-tab navigation.

I wondered if there was a specific reason for this?

Until I get your response, I commented out the inputHasFocus boolean test in UICamera.Update() method which fires or not the ProcessOthers() method in which the OnKey event is raised by your system. ('til now, it doesn't seem to have any side effect).

Thanks

24
NGUI 3 Support / [Feature request] Password Char on UIInput (code included)
« on: February 12, 2013, 06:55:22 AM »
Hi,

Since you provide a "Is Password" property on UIInput to handle password cases, I thought it would finalize the feature to add the ability to specify the character to use instead of forcing the char to '*'.
That's a really small feature request and it's also atomic enought to bring issues implementing it.

I've already made the change on my side yet I'd like to avoid that being removed every time I update my NGUI package to get all the neat additional features and bug fixes.

So here is the code I implemented myself which seems to be compliant with your approach. (Please, consider adding this ;))

In NGUI/Scripts/UI/UIInput.cs:
@line 54 right after caratChar field.

  1. [...]
  2.         /// <summary>
  3.         /// Visual carat character appended to the end of the text when typing.
  4.         /// </summary>
  5.  
  6.         public string caratChar = "|";
  7.  
  8.         /// <summary>
  9.         /// Character used to replace the text when isPassword is set to true.
  10.         /// </summary>
  11.  
  12.         public string passwordChar = "*";
  13.  
  14.         /// <summary>
  15.         /// Delegate used for validation.
  16.         /// </summary>
  17.  
  18.         public Validator validator;
  19. [...]
  20.  

@line 248, replace the existing code with this line:
  1.         if (isPassword) label.password = true; label.passwordChar = passwordChar;
  2.  

Then, we replace @line 448 in the UpdateLabel() method:

  1. [...]
  2.  
  3.         // Start with the text and append the IME composition and carat chars
  4.         string processed;
  5.         if (isPassword && selected)
  6.         {
  7.                 processed = "";
  8.                 for (int i = 0, imax = mText.Length; i < imax; ++i) processed += passwordChar;
  9.                 processed += Input.compositionString + caratChar;
  10.         }
  11.         else processed = selected ? (mText + Input.compositionString + caratChar) : mText;
  12. [...]
  13.  

Now, we need to change a few more lines in NGUI/Scripts/UI/UILabel.cs

@line 26, we add the following new field:

  1.         [HideInInspector][SerializeField] string mPasswordChar = "*";
  2.  

And @line 276, right after the password property, we add this new one:

  1.  
  2.     /// <summary>
  3.     /// The character to use to hide label content when password is set
  4.     /// </summary>
  5.  
  6.         public string passwordChar
  7.         {
  8.                 get { return mPasswordChar; }
  9.                 set
  10.                 {
  11.                         mPasswordChar = value;
  12.                         hasChanged = true;
  13.                 }
  14.         }
  15.  
  16.  

And finally, replace the previously static "*" occurrences by the mPasswordChar field value in ProcessText() method:
@line 472
  1.         for (int i = 0, imax = mProcessedText.Length - 1; i < imax; ++i) hidden += mPasswordChar;
  2.  

And finally @line 477
  1.         for (int i = 0, imax = mProcessedText.Length; i < imax; ++i) hidden += mPasswordChar;
  2.  

25
NGUI 3 Support / Re: Capturing "tabulation" input
« on: January 03, 2013, 09:23:47 PM »
I actually noticed that later on while browsing the classes for other objectives.

Just a small remark: naming your classes UIButtonXXX got me confused and I believe it does with other devs too as you'd expect them to work only with Buttons.

Thanks anyway for this great Library. I've used several on many projects for many platforms and it's really easy to setup. (still, I had liked a bit of namespace refactoring for Unity 4 but I know your reasons ;)).

26
NGUI 3 Support / Capturing "tabulation" input
« on: January 03, 2013, 12:58:51 PM »
Hi,

I've been looking around and couldn't find a way to achieve this up to the point where I had to ask the question directly.

Could anyone tell me how I can detect if the "tab" key was pressed on a UI component? I'd like to toggle the next control in the a form when hit.

Thanks

27
NGUI 3 Support / Re: NGUI namespace feature request
« on: December 15, 2012, 09:34:59 PM »
I second that namespace feature request.

I'm glad Unity finally brought namespace feature to their product.

I'd really see NGUI using namespaces as a developer friendly feature. It'll make our overall code easier to search/browse especially when you get to larger projects.
I do use UnityVS and Visual Studio to develop and I do like to structure my code with namespaces and classes to ease reading or communicating with other devs.

I understand you want to support 3.X users and that is fair. If the #define option annoys you, you could maybe consider having 2 packages or even 2 folders one for each version with a single rule in the readme file telling devs to remove the unnappropriate or to not import it...

Thanks anyway considering this request.

Regards,

Philippe

Pages: 1 [2]