Community
@NTSULZER wrote:
1. What is the better performance / say better way of doing it ?
--> If we define the "paramter" in the Child Code or if we only forward the parameter in the child rule of the parent without having the parameter espeacialy defined in the child itself ? ( LookUP funktionality )
Design Parameter_Test : Parameter_TESTRoot IvAssemblyDocument '############################################################# '#Rules '############################################################# Parameter Rule Höhe As Number = 1.5 '############################################################# '#Child '############################################################# Child Dreieck_1 As :Dreieck Höhe =Me.Höhe End ChildThis will work fine and we do not notice less performance even that we did comment out the parameter !
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt 'Parameter Rule Höhe as Number = 111
rule foo as number = hohe * 2 End DesignThis will also work but we do not really need this PARAMETER at this level !
That works OK because references to a rule will automatically "look up" to the ancestors. I added a rule which makes a reference to "hohe".
Which brings us to the second Question
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt Parameter Rule Höhe As Number = 111 End Design
2. Why does following solution not work ? The value will not be given to the child nor it uses the look up funktionality . The value will stay 111 independent of what we do in root !
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt Rule Höhe As Number = 111
rule foo as number = hohe * 2 End Design
Well, it may seem a bit odd when you show all the possible permutations here, but of course this is the simplest possible combination of a rule and a reference to it. Of course the reference to "hohe" in "foo" should get 111, regardless of any ancestor's rule.
If you want the "look up" behavior, you can add the Lookup flag, like this:
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt Lookup Rule Höhe As Number = 111
rule foo as number = hohe * 2 End DesignThat tells it to look to see if any ancestor defines "hohe", if so, use the ancestor's value, and if not, then use 111.
As to which is more performant, I don't really know. Certainly in a small model you'll never notice any difference; it will only matter if you do it hundreds or thousands of times. They all have slightly different behavior -- I would recommend using the one that makes the most sense to you. Most people are happy with the use of Parameter when they want the parent to directly control the value, and "no rule" or "Lookup" when they want a distant ancestor to control the value. Use of "Lookup" allows you to use the design in a hierarchy where no ancestor defines it (safer in one way). Use of "no rule" allows you to get an error if you accidentally use it in a hierarchy that does not define it (safer in a different way).
Thank you / Regards
NTSULZER
rule foo as number = hohe * 2
Jon Balgley
Comments below.
@NTSULZER wrote:
@Jon.Balgley wrote:
Most people are happy with the use of Parameter when they want the parent to directly control the value, and "no rule" or "Lookup" when they want a distant ancestor to control the value. Use of "Lookup" allows you to use the design in a hierarchy where no ancestor defines it (safer in one way). Use of "no rule" allows you to get an error if you accidentally use it in a hierarchy that does not define it (safer in a different way).
Thank you Jon for your answer ! However as our experiance with ETO is not proceeded far enough we would like you to clarify some things. As we are starting with a quite big project we need to define our phylosophy.
1. Most happy people: So you say to place a parameter rule in a child even if you want to control the value by the parent makes sence for many people ? "No rule" and "Lookup" for more distant ancestors ? What about the following several solutions which did all work:
1.
Here we use the Lookup even if the parent is clearly the one which can deliver the value. The rule Breite is equal to your "FOO" example! However we did also use "Me" ! it will also work without "Me" ( Somehow strange !!! )
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
Lookup Rule Höhe As Number = 111
Rule Breite = Me.Höhe*2
End Design
Using "Me.Something" is the same as using "Something".
Using "Lookup" without "Parameter" is rare, but OK. What that means is: "Dreieck expects that some ancestor will define a Hohe rule, but just in case no ancestor does that, here's a value to use."
2.
Here we use the in HELP described parent function to forward 2 time Höhe to Breite. What is somehow strange is that the model will not need to be told about Höhe itself but updated both values by just one line.
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
Rule Breite = Parent.Höhe*2
End Design
Using "Parent" means that you start the search for the rule at the next level up.
This usage is unusual/rare, because just using "Hohe" will find the parent's value.
Note that you can use "parent" to "skip over" a rule in the current design. See the next example.
3.
As you can imagine there are ( aggree bit ODD !!! ) many permutations. We like the one with Lookup and either Me or Parent . Parent seems strange though if I already use Lookup. Our tutor tells us to use Paremeter and Me.
A.
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
Lookup Rule Höhe As Number = 111
Rule Breite = Parent.Höhe*2
End Design
I agree, there are many permutations. What this one says, is: the "hohe" rule in Dreieck will look for a value in its ancestors, and if none are found, it will use 111. The "Breite" rule will ignore the hohe rule in Dreieck, and will start the search in the parent. So, if no ancestor defined a Hohe rule, then Dreieck's hohe rule will succeed with 111, but Dreieck's Breite rule will fail. This is slightly different from case 1, above.
B.
Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
Parameter Rule Höhe = 111
Rule Breite = Me.Höhe*2
End Design
The use of "Parameter" means that only the parent can control the value of Hohe (or it can choose to not control it, and let the value default to 111). The parent controls the value of Hohe by supplying it as a parameter in a Child rule. Of course, the parent can have multiple children, each of which has a different value for Hohe. (This is a key differentiation between "Lookup-no-Parameter" and "Lookup Parameter".)
As above, the use of Me is unnecessary. There is a rule for "Hohe" in the current design, of course, so no looking-up is necessary.
Because there are only these two possibilities (comes from parent or comes from default value), this is the most common technique for controlling "variable" rule values. Using Lookup or "no rule" ... it is harder to determine where a value comes from.
Can you please let us know what phylosophie makes the most sense to you ?
Here is my philosopy:
1. All the following is "in general" ... there are rare cases where it makes sense to use most permutations.
2. For most controllable/variable rules, use Parameter. "Parameter Rule Hohe as Number = 111" Refer to the rule with just the rule name, "hohe", not "me.hohe" nor "parent.hohe".
2A. Sometimes I will use :Required if there is no reasonable default value.
2B. Exception: sometimes I like to use me.hohe inside a child rule, like this:
child d as :dreieck
hohe = me.hohe
...
3. Occasionally I have a rule that needs to affect an entire subtree. In that case, I will typically include that rule as a Lookup Parameter rule in a mixin, and use that mixin in every relevant design ... and "relevant" means any design that makes a reference to that rule. By using the mixin, it ensures that the rule is available, even if no ancestor defined it. But since this is relatively rare, it is also common to carefully ensure that the root's design has definitions for these few rules, and so every design underneath can refer to them freely.
4. "Never" use Lookup without Parameter. By using Parameter, that allows the parent to have two or more subtrees with different values for "the" rule.
child a as :Dreieck
hohe = 1
end child
child b as :Dreieck
hohe = 2
end child
Finally, I agree that this is all confusing. In a simple model, such as Dreiecken, it is hard to see the point.
But all of these features have their purpose in a complex model. That's the difference between a "toy" and an industrial-strength product.
--Jon
Thank you / Regards
NTSULZER & THSULZER
Jon Balgley
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")