Even reflected property types should be of trivial types: 1. build in types 2. std::string 3. types that can simply be read from /written to strings.
Here is where we disagree. One should be able to make properties which encapsulate classes or data structures themselves. It is quite common to make a property which is a pointer to another component type and allow the
Really? Which would those be? I can only think of the "buddy" property of a spin control.
programmer at design time to connect that property to another component which has also been dropped into the design time environment and configured separately. Furthermore it is also quite common to make embedded properties which are themselves small components with their own sub-properties. This latter is often a good way to organize properties in a way that makes it easier for them to be understood and set.
This can be achieved visually in other ways. That is, once you create a control, you can define (probaly in a easy scripting language) how to group properties together.
For case 3., you might also have a validation function which will be used in design-mode to validate user input.
Both .NET and C++ Builder allow one to do validation of a component property at design-time, which is actually run-time for the component. This is another reason why run-time reflection is better than header file parsing. One is already in a run-time environment for components when they are being dropped on a form, so why not use the full abilities of a run-time reflection mechanism.
You could be right. I need to put more thought into it. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html