The filtering is applied to both the treeview and the Internal Block Diagram. There are a few basic rules that control the filtering; they are presented here. These principles apply to both object types and type attributes.
Let us start with an example: a Tree contains Apples containing Seeds. Our filter will show this hierarchy, showing every component.
A seed producer could assume that the number of Apples per Tree is constant, making the amount of produced Seeds proportional to the amount of Trees and thus abstracting the notion of Apples. The corresponding filter would be defined as:
When using this filter, the Seeds will be considered direct children of the Tree (all other rules still apply). There is no restriction on the filtering level, each rule within its context can be filtered independently.
Now let us add a new type of fruit:
In this example, the Seeds are hidden when they come from a Pear but not when they come from an Apple. This illustrates that filters are not applied to plain types but to rules, i.e. types in a given context.
Now imagine that after having played with some DNA, we have created an instance of a Seed which can come from both a Pear and an Apple. What would happen if we applied the filter shown above to this instance?
The following rule would apply: an instance is shown in a treeview if at least one of its references is not filtered. In our case, the Seed would be visible.
Another special case could be triggered this way:
If our DNA-tweaked seed is both a component of an Apple and a Pear and if both the Apple and Pear rules are hidden, should the seed be displayed twice as the child of a Tree?
The answer is no: when the filtering creates several references to the same object at the same place, they are all merged into a single object reference.