I’ve just noted, I can reference an attribute of another component that is in the model, example:
Component: Step_Dad
Hair = “blonde”
Component: Son
=If(Step _Dad!Hair=“blonde”,“blonde”,“brunette”)
Here the Son has no direct DNA connection to his Step Dad, but can seemingly inherit his hair colour. Is this intended functionality, and is it stable and trustworthy? This is a game changer for us if it is, we can have a Master Component that contains “job” common properties!
Can’t replicate this, but if you wrapped the whole model in a DC you could do what you are suggesting I think. Keep the job stuff at the top level and pass it down to all child DCs…
Step_Family.skp (79.6 KB)
Huge thanks for trying to replicate! I do wonder why this is only happening at my end; I myself had never seen it before!
The idea of a manager component was our fallback plan; we have labels within our panels that auto-update. If we flip the entire job, they flip also. So by placing them in the manager, we can call up flipped along the axis and flip back all the labels to their correct orientation.
By incorporating this manager, whilst its primary function is to flip and manage levels for LayOut, we can use it to control those “job” common properties.
I just went back to my previous post regarding flipping, @ryan.moore, you’re the chap would fed me the idea of the flip manager! Double Thanks!
Is there a group instead of a component involved? Groups can end up tied together in weird ways…
No both are components! I thought it may have been that I pasted the wall component into the manager, changed a manager setting, then cut from the manager and pasted back outside of the manager. Changing the manager thereafter changed the panel. But to test, I created a new manager and new references in the panel, and again this manager could affect the panel. Very strange!
Hmm, that is strange. I wonder if Philip @pcmoor can shed any light on this?
I have been watching this with great interest, so I decided to test it myself…
I can have an independent “Master” DC, and a “Child” DC which will read the “Master”, but for it to update to the “Master” DC values I have had to add the “On Click” option to force a Redraw.
Placing a new copy of “Child”, it auto updates to the latest “Master” value.
That may help a bit, but I doubt auto-redraw is available in this context for previously placed copies of the “Child” component. Therein lies the big risk as there is no obvious indication that the “Child” has correctly updated to respect an updated “Master” variable.
I’m on macOS Tahoe 26.6.2 with SU build 26.2.242
DCMaster.skp (304.2 KB)