I *think* what you envisage is based around collecting data from the user via dialogs. So in your view of things, there would be a C++ object that holds the collected data, a set of validation routines, and a reflection map that binds these to the UI. But you don't do anything to the program state until the user clicks "OK" in your dialog, at which point you suck the data out of your simple C++ object and act on it.
In contrast, other people (myself included) are considering binding properties and member functions to the UI for similar purposes to why you would expose them to script: to allow the user to drive them. So, for a simple example, let's suppose you have some object that corresponds to a file:
class file_backed_t { public: std::string get_filename(); /// This actually renames the file on disk. void set_filename( std::string const& ); };
Now, when you bind the filename property to the UI, you'll automatically do the rename as soon as the user changes the text in the edit box. (Probably that isn't the desired behaviour in this case, but it serves as a demonstration.) This usage pattern corresponds better to modeless dialogs where you don't have an "OK" button.
Note: I support both modeless and modal dialogs (more to the point: saving data can happen automatically - click of "Ok", or programmatically). Usually, you need more validation than a simple filename. The user could enter data into more controls, and once the user is done, you run the validation routine(s). This is the transaction commit/fallback pattern, which is much better the direct binding IMO. Also, notice that when doing validation with save_dlg, when a validation routine is called, you have acess to more states of your data: - the original value - the old value - the last known good value (the last value for which all validation code succeeded) - the new value When a validation routine is called, you can set an error, or for instance, simply set the value back to the - old value - last known good value - or whatever you wish. I would say this is very flexible. Hopefully in the near future I'll have the time to update the docs so that people will understand the save_dlg's full power. 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