Member 10794476 asked:
I am able to do it as enumeration and it is static. If I want to generate the property values programatically at runtime, what would be the best possible way to do it?
There are two different questions here, second one depends first, but first is unrelated to second.
First one is about "dynamic properties". Roughly, this topic could also be subdivided in two.
One-A topic is: you can generated code dynamically using
System.Collections.Emit. But it is possible only when you generated the whole assembly. The approach without generation of assembly also exists:
DynamicMethod, which is largely irrelevant to "properties". So, you generate the whole assembly, will all classes, structures, and all properties you may imagine. But what's the use? How to use these properties if they are dynamic? You want have any predefined compile-time interface to work with the code generated on the fly. Just think about it. By property names, or some descriptors (name + property type)? Possible, especially if the set of property types is a compile-time entities. But would it worth the effort?
I would say not, because, if you create such a machinery for accessing properties, it would outweigh the use of generated assemblies (which are actively used, but for implementation of purely internal
behavior; one example is
serialization). Why all these complexity (using
System.Collections.Emit is quite difficult; it requires good knowledge of CIL and the generated code is quite hard to debug)?
So, we are coming to the
topic One-B. It brings us to the different idea: you can
model the behavior of properties. The simplest mechanism is this: for example, you can create dictionaries of the types
System.Collections.Generic.Dictionary<string, PropertyType>, where
PropertyType value represents the type of property, and string key represents the property name. Several different property types? Well, you can either (again, solution choices split) use several dictionaries, one per property type, or use
polymorphic (by property type) dictionary representing set of properties of mixed type; and you still can have different instances of different dictionary type with different
base types and than use OOP approach for each of the dictionary instances.
That's all on the first question; now let's
return to the
PropertyGrid. It can be customized in the following way: instead of
PropertyGrid.SelectedObject, you should use not the object itself, but some other object representing the object you want to show in some customized way; let's say, it will be the object wrapping the object you want to show. The idea is: this wrapper object should implement the interface designed to collaborate with
PropertyGrid:
System.ComponentModel.ICustomTypeDescriptor. I describe this technique in my past answer:
How to get response when click PropertyGrid, in detail and some sample code.
Using this technique, you can represent whatever you want (including the objects of types generated with
System.Collections.Emit and the object "mocking" the behavior of "object with properties" actually modeling property behavior. You show any structure using any semantic ways, not in general way.
As you can see, you are facing a number of choices, hierarchically, and good amount of not very simple work, which is partly architectural. The decisions you are going to make will depend on the detail of what you want to achieve (I guess, you have yet to determine that, too), and the consequences of these decision would be very influential. Just face it: this is the load not everyone can carry. But I don't want to discourage you: it can be a really good level of programming with fruitful result, and in case of not very successful result, would not be a complete waste of time, such experience can be very useful.
[EDIT]
This answer is continued
here
—SA
Submit an article or tip