Odd anchoring bug occuring when parent panel is being animated

[skullthug]

Hello. I've been running into an issue with basically what the subject says- I have a UIPanel I'm animating with an AnimationClip and somehow a child sprite of it is failing to anchor properly (it anchors somehow outside of the frame). Seems to happen with both the OnStart & OnEnable methods of anchoring, but works fine with OnUpdate. I'd prefer to avoid OnUpdate as it seems un-necessary and I've run into issues with it in the past being expensive. Also all other buttons on the screen are using OnStart/OnEnable fine and they are of the same setup.

I recorded a video of it happening for clarification (it occurs on the Back button)
https://www.youtube.com/watch?v=aQRqpc7kfi0&feature=youtu.be


I'm a little stumped, mainly because before it was just the Back button it was happening to a decent chunk of the buttons on that screen. I suspect I'm skirting on the edge of some sort of execution order.

[Ferazel]

I've had situations similar occur. NGUI has some optimizations on widgets/panels that are too small or too transparent for it to care about. (i.e. When the scale is 0 or when the alpha of a widget is 0). In the scale problems, changing the tween from a starting value of 0 to a starting value of 0.01 seems to have helped. This might be what your problem is.

See if you can keep the widget from culling itself by having its alpha start at a very small number rather than 0. 

[ArenMook]

OnStart and OnEnable anchors are executed only once. OnUpdate are executed every frame.

If you are animating something, why have anchors underneath it? Why not put anchored content on a separate panel?

[skullthug]

Right.
I had just assumed animating a panel would be acceptable practice, because as you can see in the video it works for the majority of the other UISprites except one odd duck.

[skullthug]

Tried putting the anchored content on a separate panel underneath the animated one to see if that would help, but I still had the same issue.
Just to update, I managed a hack solution by doing WaitForSeconds(.01F) after doing SetActive(true) to the panel object being animated, and before I trigger the animation clip. That seems to allow the anchoring to do its thing without the animation messing it up.

[ArenMook]

I didn't mean creating a child panel. I meant moving anchored stuff outside the animated panel altogether.

[skullthug]

The anchored stuff is what needs to be animated, so er.. I'm not sure I understand the point?

[ArenMook]

Widget (anchored)
- Widget (animated)

[skullthug]

I'm afraid since I anchor so many buttons to respective corners for a differing range of screen ratios, I don't think that setup would work too well in my case.

I discovered another thing that was causing odd problems, possibly related. It is that one of the non-NGUI cameras was accidentally set to render the UI layer, so two random panels (opposed to all of them oddly) would keep referencing that non-NGUI camera in regards to anchoring in the Editor view. While in this state, the only way to "reset" the anchoring was to toggle the Padding checkbox item in the UIPanel for each, after which it would be correct for the next Play-run in the Editor but it would reset to the bad anchoring after ending Play.
After disabling rendering of the UI layer on the non-NGUI camera and "resetting" via the Padding checkbox they finally seemed to remain in the correct spot after running in the editor.

That paragraph was a bit convoluted I admit, but I hope it made some sense. I can record a video if that would be more helpful. It was confusing and was very difficult to figure out why the Panel would not stay put.

[ArenMook]

That seems logical. Only one camera must draw the UI.