If you use the DrivenRectTransformTracker struct to prevent some values from being modified in the inspector, but then save out the scene the values are not saved with the document and you get all zeros. I am trying to create some advanced Layouts and controls not saving there size hurts me.
Not that this helps, but in case youâre hoping this is a bug and not noticed the docs it looks like that is by design: âThey also wonât be saved when saving a scene, which prevents undesired scene file changesâ, which is actually the behaviour I want at the moment. I guess the thinking behind this is that whatever is driving the values will also do so on loading the scene etc.
This is by design. See here under âDriven Rect Transform propertiesâ: http://docs.unity3d.com/460/Documentation/Manual/UIAutoLayout.html
Driven properties are meant to be recalculated when the scene loads to ensure theyâre correct. See the section on the same page called âTriggering Layout Rebuildâ.
1 Like
Doesnât this only encourage poor prefab design? It is very useful to align things directly in the prefab and then leave it locked via a custom layouter. This design renders DrivenRectTransformTracker unusable for anything other than the official Layouts which also by design are poor performing (updating every frame and dirtying the canvas hierarchy).
Is there a way to make it still save? Would it be too much to ask that this be exposed as an option you can set on the tracker?
For now weâll just have to turn this back off for our custom layouters. 
Iâm not sure I understand what this mean. What do you mean by leaving things locked in a custom layouter?
In general, driven properties are properties that are calculated as a derived result of something else, not human authored values. And these calculated values may change based on all kinds of things, such a the current screen resolution. These changes should not go into saved data - it would cause it to change e.g. whenever you tested with different screen resolutions. So this is absolutely by design, as stated.
If you just want some values to be read-only in the Inspector, but still save them as normal, the DrivenRectTransformTracker is not designed for this purpose at all.
It may be that Iâve been misusing or misunderstanding what the DrivenRectTransformTracker is for, but I can tell you the use case weâve been using it for.
So we made our own HorizontalLayout, VerticalLayout and GridLayout so that we could control when they aligned, either OnStart, OnEnable, OnUpdate or customly when we change the data in the labels/sprites, and to measure the full subhierarchy instead of the first level LayoutElements. This means that for HorizontalLayout the AnchorPositionX is driven by the layouter. If anything else, or someone from the inspector, started setting the AnchorPositionX it would be badâ˘.
This is all well and good, when you run the aligner consistently every time you modify the hierarchy under the layouter, but when a thrifty developer then thinks he can just run the aligner in prefab mode, calculate the values there as default and then not run align again unless its needed the values, he intended to save and not re-calculate, are just 0. We just spent some time hunting down a bug because of it - granted, reading the documentation would have explained it, but several hours of bug hunting can save minutes of documentation reading. 
Like you said, I guess I was seeing it as a way to set the RectTransform inspector element to indicate that the value shouldnât be tampered with by anything else. I also suppose that it is implied that if you use it, the driven element would be driven constantly, which makes it make sense not to dirty the prefab save constantly. We just sorta⌠drove it for a little bit and wanted to leave it where our driver finished.
Right. So youâd like a way to prevent people from modifying certain values, but still have those values saved.
I donât believe we have a way to mark properties on builtin components as read-only (driven properties have it as one effect but as discussed they serve a different purpose). One thing you might be able to do is recalculate the values more aggressively in Edit Mode, ensuring theyâre set back to the right values if a user is changing them, but still not touch them in Play Mode / builds. Essentially doing things similar to how the builtin layout components do it, but have the logic onto take effect if the object is not part of the playing world (use Unity - Scripting API: Application.IsPlaying) and also not actually use the DrivenRectTransformTracker.