UIPopupList Set Bug?

[Maxii]

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.

[ArenMook]

It's intentional. The popup list only has a value during its callback function. I've mentioned this on several occasions in the past. If you want to store this value, do just that.

1. public string savedValue;
2.  
3. void Start ()
4. {
5.     var popup = GetComponent<UIPopupList>();
6.     EventDelegate.Add(popup.onChange, delegate () { savedValue = popup.value; });
7. }

[Maxii]

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!