Bizzare Display Problem in PC Stand Alone

[blitzer]

Hello everyone, I've got a UI setup that (in the Editor anyway) scales and re-sizes perfectly with different screen sizes / aspect ratios at runtime. However, when running the game in PC Standalone mode, the display (specifically a screen that uses a UI ScrollView) changes dramatically, and I'm not sure why. See the attached images for exactly what I'm talking about.

If anyone has an idea of what is going on, I would really appreciate it.

[ArenMook]

What is it anchored to and how?

[blitzer]

About the setup:
UI Root -> set to fixed size

The UIScrollView is on a UIPanel (alpha clip) which has unified anchors to a UIWidget parent.

The UIWidget parent has advanced anchors: (top/left/right) are anchored to another UIWidget parent (which is the same size as / anchored to the master panel), and the bottom anchor is set to the top of the "Begin" button UIWidget.

The grid itself and its child UISprites have no anchors.

-----

[blitzer]

Added some labels that show the size of the panel with the scroll view and the size of the container that the panel is anchored to -> the issue seems to be with the panel (and it having anchors). Note in the pics below, the container stays the same size, but the panel is dramatically different.

I have noticed that when the alpha clipped panel has no anchors, it seems to display the same in the editor and in the actual standalone build. Is it possible that somehow the anchors on the clipped panel are not recognized properly when outside of the editor?

[ArenMook]

The new layout system works the same in the editor and in builds, and updates every frame (assuming the Execute is set to "OnUpdate" and not "OnEnable"). Have you tried adding some NGUIDebug.Log statements to UIPanel.OnAnchor to see what kind of dimensions it's working with?

[blitzer]

 Have you tried adding some NGUIDebug.Log statements to UIPanel.OnAnchor to see what kind of dimensions it's working with?
- I had tried them on my script that re-sizes the components, but I will try your suggestion and see what comes back.

In the pics below, for some reason after the anchor update, the panel actually gets smaller, and always becomes 20 x 20 no matter what the screen size is or parent anchors are. Everything else seems to be fine.

Update:
I added new ngui debug statements to OnAnchor, and it seems like while in the editor, OnAnchor thinks that it has sides, but in the stand alone game it thinks sides is null:

[ArenMook]

What are the sides, and what does the call stack look like when they are null? (you can Debug.LogError something when it's null and see the call stack in the log file).

[blitzer]

I tried to get you the call stack, but I just get back the same information as a regular Debug.Log (I'm sure I'm using it wrong).

I've actually re-written the script as well, and the only problem remaining is that when you click on a child object in the scroll view for the 1st time, the panel's contents "jump" to the left then get pulled back to the center. It seems like this "jump" is the same movement caused by resetting the panel's content origin to the top left (in the inspector as the game is running), then the UICenterOnChild script pulls the object back to the center. I have been unable to correct it.



Update:
Apparently the jump problem was fixed in a new version of NGUI, thank you again ArenMook, I always appreciate the help on and continued development for NGUI.

-Spoke too soon, now instead of jumping on first touch, the grid and its contents make a very quick "slide" into position the first time they become visible on screen, it seems that UICenterOnChild takes a few frames to complete, even when site to a high spring strength. Is there a way to ensure the adjustment takes place in 1 frame?

[ArenMook]

Set the UICenterOnChild's spring strength to 1000 and it will complete on the next update.

[blitzer]

Unfortunately, I already tried that. In the end, I just made a custom method in UICenterOnChild that makes the adjustment instantly (it doesn't seem to have any drawbacks or problems so far). Either way, I appreciate the ideas.