Messages

1

NGUI 3 Support / UIRoot and static GameOjbect children

« on: January 10, 2017, 01:51:53 PM »

I"ve been learning about GameObject.static. From what I read, since UIRoot scales the entire gui heirarchy (when using pixel perfect...), is it then true that I should never have a static Gui element underneath UI root, aka all Gui element game objects under UIRoot should be non-static?

2

NGUI 3 Support / Re: UIPopupList Set Bug?

« on: September 19, 2016, 01:49:44 PM »

Thanks for your quick response. I kew that certain things weren't valid except during an event (static current for instance) but I was unaware of the change to UIPopupList.value until I experienced it updating to 10.1. My apologies if I should have discerned this earlier. Still love your product!

3

NGUI 3 Support / UIPopupList Set Bug?

« on: September 16, 2016, 02:24:12 PM »

I just updated from 3.9.6d to 3.10.1 and immediately started seeing an issue with UIPopupList having a null [selected]value. I think this happened when you added the optional ability to not trigger a callback in Set(value, notify = true). In this new Set(), if mSelectedItem should be changed, you change it, determine whether to notify, then set mSelectedItem to null, aka after using value_set or simply Set(), value is set to null right after TriggerCallbacks(). This last part of setting mSelectedItem to null wasn't present in 3.9.6d. Is this intended? If so, the only time value has its assigned value rather than null is during the callback, assuming the client chose to trigger it. If they don't choose the callback, value will always be null... Obviously I'm confused by this, but I do know that PopupList.value is always null except during the callback. As I use PopupList alot, I'm dead in the water right now.

As an aside, in both sets of code, you test for mSelectedItem being null after being assigned value and return if it is null which makes sense to me. However, when testing notify, you again retest mSelectedItem for null which it can never be. No harm done, but just thought you would want to know.

4

NGUI 3 Support / Re: UICamera.onHover

« on: February 08, 2016, 08:20:02 AM »

Yes, I do mean 2 OnHover(true)s without an intervening OnHover(false). I do not mean 2 OnHover(true)s without anything else intervening.

The stack you provided shows the issue I'm raising. Shouldn't there be a OnHover(false) in it if there is a second OnHover(true) whos intention is to "restore the visual state" as indicated by the comment?

I think you are telling me that multiple OnHover(true) can arrive on the same object without an intervening OnHover(false), and that it is intended. Please confirm.

One other piece of info: I have the fallthrough GameObject assigned if that matters.

Using latest version 3.9.6d

5

NGUI 3 Support / UICamera.onHover

« on: February 07, 2016, 09:12:30 AM »

I'm finding circumstances where multiple OnHover(true)s are received on the same object without an intervening OnHover(false). Is this intended?

It is coming from UICamera.ProcessRelease() where your comments suggest you are trying to "restore the visual state of the object", implying of course that an OnHover(false) has already been called and now needs to be restored back to true. This multiple trues in sequence occurs when I click on an object, aka ProcessRelease().

I notice you've commented out sending OnHover(false) from selectedObject.set. The only places I now find it is hoveredObject.set and controllerNavigationObject.set.

I'm guessing this is unintended as I seem to remember encountering a similar issue about 2 years back which you then fixed. :-) Please clarify.

I've been using Ngui now for about 4 years. Wonderful product. Thank you.

6

NGUI 3 Support / UIPopupList onChange EventDelegate

« on: June 10, 2015, 04:18:18 PM »

I've noticed that the onChange EventDelegate for UIPopupList is fired whenever UIPopupList.value is set, even if it is set to the same value it currently holds. Shouldn't that be limited to firing when the value is changed, not just set?

I'm using 3.9.

7

Misc Archive / Re: Building Material Design UI with NGUI

« on: April 11, 2015, 10:53:22 AM »

What ever happened with this amazing work? Did is get to the asset store?

8

NGUI 3 Support / Re: Update to most recent version slows Unity

« on: November 28, 2014, 04:58:32 PM »

Did anyone ever find a real problem with Unity4.5's GetComponentInParent() and/or interaction/slowdown with Ngui?

I'd like to change over to using it and replace my own version if this turned out to be a non-issue.

9

NGUI 3 Support / Re: BoxCollider2D verification and UIRoot scale

« on: November 27, 2014, 07:31:41 AM »

Thanks for the insight.

Do you know if they view it as a bug to be fixed, or is this just a limitation of the NVidia physics engine that all will have to live with?

If they will eventually fix it, I'll defer switching over to 3D colliders for awhile.

10

NGUI 3 Support / BoxCollider2D verification and UIRoot scale

« on: November 26, 2014, 03:55:29 PM »

I've just encountered something unusual and would like to get your thoughts on way forward.

I've got buttons on my UI. I like to keep them relatively small - 20 -25 pixels square or so. They have 2D BoxColliders on them which are resized automatically depending on the widget's size. WHen I recently pushed MaximizeOnPlay to demo the UI, I found I could no longer detect these small buttons. It turns out the collider posted a warning in the collider inspector saying the physics engine had failed to validate it because it was too small. My screen height was 1040 (1200 less UnityEditor menu bars, etc.) and UIRoot's scale (flexible style as I'm on Windows and Mac platforms) was 0.00192307 which all makes sense.

After some experimentation, it seems that these colliders, when UIRoot reduces its scale to the value above, need to be a minimum of about 27-28 pixels in both x and y in order to validate.

Now of course I can simply increase the minimum size of all my sprites that contain colliders, but that seems like a temporary hack. Before I go down this route, I'd like to know your thinking on how this might be dealt with more systematically, assuming of course that you have encountered it before. I have found nothing in the forums to date on this, except acknowledgement in Unity that colliders can be too small and not validate.

11

NGUI 3 Support / onPress delegate gameObject null

« on: November 08, 2014, 02:53:32 PM »

I've just encountered a situation where the gameObject sent with the onPress delegate can be null even with a gameObject assigned as the fallthrough. While I can filter it out, I wanted to mention it as it could be a bug unless intended to operate that way. Looking at the UICamera code, I can see you choose to send out a onPress(false) before sending a onPress(true) which clearly is intended. (Not sure why, but I am sure there is a reason  ). I'm seeing the null gameObject when the initial onPress(go, false) is raised.

12

NGUI 3 Documentation / Re: UIWidget

« on: October 18, 2014, 11:15:30 AM »

Ahh! That did it. I was scaling my widget underneath the panel. Once I moved the scaler above the panel, onChange only fires now when I would expect it too. Thanks.

13

NGUI 3 Documentation / Re: UIWidget

« on: October 17, 2014, 09:17:20 AM »

Just to clarify - do you mean

1. OnChange will be called if the widget gets moved relative to the panel that manages it, or its size changes relative to the panel that manages it, or
2. OnChange will be called if the widget moves at all or its size changes relative to the panel that manages it.

14

NGUI 3 Documentation / Re: UIWidget

« on: October 14, 2014, 05:32:16 PM »

The check for a change in width/height is the current filter I use to ignore 99.9% of the onChange calls right now.

My reading of the comments on the event and methods led me to believe that onChange should only be called when the widget moves relative to its panel which I believe you are confirming. From my testing, when I rotate the panel that manages the widget (without moving the widget relative to the panel), I'm getting an onChange event every frame - aka hundreds per second until the rotation completes.

My filtering works fine. It just seems like a waste of effort when I have to filter it every frame to catch the .001% of the time when I change the dimensions. Thought you should know about the observation. Thanks for the support as always.

15

NGUI 3 Documentation / UIWidget onChange

« on: October 13, 2014, 11:04:02 AM »

My objective is to be notified when UIWidget's dimensions change. I've found UIWidget.onChange which is described as "Notification triggered when the widget's dimensions or position changes". In the code, onChange is raised in UpdateTransform() whose description is "Check to see if the widget has moved relative to the panel that manages it".

As I only want to know when the dimensions change, I'm not interested in being notified when the widget moves relative to the panel, so to eliminate those notifications, I've placed my 'faceCamera' script so that it rotates the panel rather than rotating the widget, thinking that this way, the widget won't move relative to the panel. Unfortunately, whether I rotate the widget underneath the panel, or rotate the panel directly, I still get all the widget onChange notifications of movement.

Am I misunderstanding something here? Shouldn't rotating the panel directly keep the widget from generating all these onChange (aka I moved relative to my panel) notifications? ... or is the "Check to see if the widget has moved relative to the panel that manages it" comment misleading, and any absolute widget movement raises onChange?