Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-11-15 06:51:22

>>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.


John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons (work for MessageBox too!)
    + tab dialogs, hyper links, lite html

Boost list run by bdawes at, gregod at, cpdaniel at, john at