Right. Grandparent, parent, child... and on and on.Well, in his skin, he "upgraded" the technical parent into a "super parent", since he's a super fellow of a super Rainmeter himself...![8-)]( "Cool")
Joking aside, I see what you mean now: structurally speaking, his location, current condition and forecast days measures are indeed parents but only to their own children, since they're at the same time children of the technical parent which connects to the site and is not a child of any other WebParser measure (thus, a "pure" parent, so to speak). This is what I meant earlier.
Yes, I agree with your assessment, as it provides some insurance against future changes. Thanks for your input.That's up to you and your preference, for example if you want to be consistent all around the skin you could do that. From a functional point of view, since the whole point of this approach is to avoid those initial errors on empty / invalid values in the dependent Time measures by disabling them, if other parts of your structure don't need disabling to avoid errors, you could skip doing that. Personally, I usually go with consistency, just to be on the safe side in case it's needed at some point if I edit the skin in a different way or add some dependent measures requiring that later on. In his skin, jsmorley had dependent Time measures for nearly all his lower level "parents", so he disabled the latter along with the former, even though the latter most likely didn't technically need it.
Statistics: Posted by qwerky — Today, 5:32 pm