To make the TypeDescriptor you wrote work, you can write your own TypeDescriptionProvider and TypeDescriptor.
1) Write a class that derives from Microsoft.VisualStudio.Modeling.Design.ElementTypeDescriptor, say MyTypeDescriptor class. In the class, override the base methods you'd like to override. In particular, you want to override CreateRolePlayerPropertyDescriptor() method. The method passes you the source role-player and the target role as parameters. Say you want to filter relationship ARefsBs, then check if the source role-player is an instance of A and the DomainRelationship of the target role is ARefsBs. If so, return an new instance of the RolePlayerPropertyDescriptor that you have written earlier in this thread; if not, just return base.CreateRolePlayerPropertyDescriptor().
2) Write a class that derives from Microsoft.VisualStudio.Modeling.Design.ElementTypeDescriptionProvider, say MyTypeDescriptionProvider class. In the class, override CreateTypeDescriptor() method to return the descriptor in step 1 above.
3) Say you want to filter a relationship ARefsBs. On the source role of the relationship, A in this case, register a CLR attribute: [System.ComponentModel.TypeDescriptionProvider(typeof(MyTypeDescriptionProvider))]. You can do this by writing a partial class to of generated A to add the attribute, or you can add a ClrAttribute in your DomainModel for DomainClass A, so the attribute is generated for you directly. If you choose the second approach, there's currently a bug in the attribute dialog that you can't type in the parameters easily, so you might want to edit the dsl file in XML editor directly.
The above steps should cause your type descriptor to be called when displaying an instance of A in properties grid, which calls your RolePlayerPropertyDesciptor to display role Bs. So if you have overridden ElementLists property in your role-player property descriptor correctly, you should be able to filter the results. Thanks!
Frank Fan [MSFT] |