You have made a good point. I still feel uncomfortable about parsing header files to determine type information. If header files were used, since run-time reflection does not exist, one would have to inject the correct code into source files based on design-time decisions. But it does seem as
I think reflection in general is very different from reflection for a GUI.
When you have a GUI control, you want to apply reflection for a few of its properties. You won't have #ifdefs (or at least I would consider it bad design). Case in point: its interface should be extremely simple and easy to parse.
You shouldn't need complex information like reflection for virtual functions, overloading etc.
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.
For case 3., you might also have a validation function which will be used in design-mode to validate user input.
At least that's what I want.
I'm not sure that is valid. Take a TreeList as an example. The items in a treelist are almost always sub-classes, based on some type of generic 'TreeItem' class. I'm not sure that a TreeItem can always be represented as a string. Also, the position of a treeitem (within the treelist), may not necessarily be able to be stringified. Mathew