linking a dynamic rule to a specific member of a child list

[JonSchmid]

Hello All,

I am working on a model in which there is a Child List of parts. The user interface allows the user to control a particular Rule value within any member of the list by writing the new Rule value as a Dynamic Rule to that Child.

The problem comes when other, higher level inputs to the model change the length of the Child List in question.

As an example, say the list has 5 members when you write a dynamic rule value to the 4th member. Then something happens that deletes the 2nd member of the list. Now you only have 4 members in the list, but the dynamic rule value is still being applied to the 4th member of the list, when it should now be applied to the 3rd member.

Who has dabbled in some ways to make sure a dynamic rule would stay applied to the intended child in such a situation? Some thoughts that have crossed my mind:

1: never allow the length of the Child List to become shorter... rather, if you need to delete a member, change its Design to nulldesign, effectively deleting it while the other children maintain their positions in the list. New children would always have to added to the end.

2: don't use a Child List at all, rather create a set of dynamic children, each of which carries a unique and consistent name... then apply the UI selection as a dynamic rule to the one of interest. These can then be created and deleted as necessary (through the API, not "makepart()" or anything like that).

3: don't write the dynamic rule to the member of the child list, but write it to the parent in such a way that each member of the list can look for a value that applies to him before resorting to his default (this would be awkward for my particular case, but just a thought).

Any other ideas? It would be great if a dynamic rule could be applied not by the simple "refchain", but to the nha.refchain + the child displayname. The Displayname could then be unique and consistent based on the child's true identity, without consideration of it's place in a child list.

Jon Schmid

[Jon.Balgley]

What do you mean, "something happens that deletes the second member of the list"?  If you are to take that literally, then I think you must go with solution 1 or 2.

I don't think that changing the quantity from 5 to 4 is the same thing as "deleting the second member of the list".  That's the basic flaw.  

Your solution #1 is OK where you have a well-defined "maximum" or "total" quantity of children, and individual ones need to be turned on/off.  I.e., you have 5 children, but "delete" #2.

Solution #2 is straightforward from ETO's perspective.  It may not be easy/practical in a given scenario.  Seems to me that this is more applicable where you have highly variable "quantities" of children.  

I don't think you can make #3 work.  You will eventually have a need to assign some identifier to a given member of the child list, and that must be done in an "indexed" way, which defeats the purpose.

[JonSchmid]

Hi JonB... long time, no see!

In this case, the Child List is being built off of a list of data... one Child for each entry in the list, and it receives that entry as an input. So when I wrote "something happens that deletes the second member of the list", what I meant was that the User's inputs change the length of the list of data, and as an example the datum that was second in the list is removed.

As a real simple example, say you have a list of numbers which be the heights of a Child List of cylinders... e.g. {2,4,7,11,13}. Intent creates the Child List, then let's say you want the cylinder of height 11 to be a special color. So you write a dynamic rule to the 4th child in the list "rule color as string = 'blue'".

Then you change your inputs to the application, and the list of numbers now becomes = {2,7,11,13}. Now the dynamic rule will be applied to the cylinder of height 13, when what you still want is the 11 height cylinder to be blue.

Solution #1 would be a bit difficult for my case. A variation of Solution #2 is what I ended up with.

And I think that for a simple enough scenario, solution #3 could work; in fact, the "variation" of solution #2 employs that idea. Each child constructs a unique and consistent identifier not based on his index, but on the values of the input parameters he receives. It would be like if each cylinder created in the example above had a specialization of the rule "color" that would first look to the parent for the existence of a rule "color_for_cylinder_height_11" and, if found, would use it, otherwise use a default.

Anyhow, I think I have something that is working... still in the middle of implementation, but it looks promising.

Thanks, Jon Schmid