I have not been idle with the TRAP project. I merely hit a snag this weekend that I have not had time to unsnag. I have been working on the
visual interface to creating the mapping files. Given that this is a code-like operation, I decided to use the built in Designer functionality. After all, Microsoft spends
billions on usability studies before they release a product, so I'm just going to ride that wave. If they say the PropertyGrid is the best way to edit a set of attributes, then I say
use the PropertyGrid.
There's the problem though, "Designer Support",Browsable, EditorBrowsable, PropertyGrid, DesignerSerializationVisibility, CollectionEditor, UITypeEditor, TypeConverter, StandardValuesCollection. Ever use those? Many .NET developers, even the best ones
I know (yes far better than me) know little or nothing about what you can do with the built in designer support and designer classes in .NET. There's really three categories of things you can do with all this great stuff.
- Create your own visual designer to build something visually. (Like my WYSIWYG Mobile printing code)
- Add designer attributes to your code, if you are developing a control that many people will use or that you plan to sell. There are some differences in the designer support for Asp.Net versus WinForms.
- Use the built in Designer code to "configure" something within your UI. This is what I am doing with the TRAP UI.
I have shown once or twice a screenshot of some Mapping related class inside a property grid. Big deal, right? Well, as soon as you increase the complexity by only showing some of the properties, or
editing collections, or wanting to support a list of acceptible values in a dropdown, or wanting to customize the way the editor looks, or wanting to edit nested properties of types with their own properties, things get
somewhat complicated fast. There is also practically no documentation or examples to be found, making this an obscure area of .NET knowledge.
I have most of what I want for designer code working in the TRAP UI now, and that alone could make a pretty decent Designer support tuturial. However, I ran into an issue and the code needs to be cleaned up. On the component diagram
I showed a UI assembly and a Types Assembly, where Types is not allowed to depend on another TRAP assembly. Well, once I started adding all of the attributes and custom collections (and there's a lot) needed to give me
the designer behavior I want I hit a snag and need to refactor. There is a designer class called
StandardValuesCollection that you can create from within a
TypeConverter; this class makes it so that if you edit a certain value
in the designer you get a ComboBox with your value list in it rather than a TextBox where the user could type anything. Well, by placing all these designer attributes and classes within my Types, I eventually found a dependency on the UI project,
in this case it was getting the Project context from my
Component Director so I could list the database Tables as StandardValues. I now need to completely clean the types of all this knowledge and create "Designable Types", and use a
Decorator pattern or something like it
to have designable versions of the types. When that is done I will show some designer code samples.
Subscribe