Hi John, John Torjo wrote:

...

BEGIN_DATA_ADAPTER(SomeSettings) PROP(m_aMember) PROP(m_struct) PROP(m_strings) END_DATA_ADAPTER()

Sure thing, but how about *true* bindings? http://www.torjo.com/win32gui/save_dlg.html

you are missing my point. I want a higher level of abstraction. win32gui is nice if you have a simple 1:1 binding for a struct - dialog scenario. But it will kill you if you have a frame window with a notebook as a client, several notebook pages with splitter windows, list boxes forms etc... I don't think I would like to do that using your 'save_dlg' setting. You need a way to break it up into small, manageable parcels. The Lit Window Library (http://www.litwindow.com/library) also lets you specify complex bindings that evaluate C++ expressions: Frame.Title = "Headline: " + myStruct.m_title The framework reevaluates Frame.Title everytime myStruct.m_title changes. The data abstraction layer requires some macros, which btw are using templates and are type save, but allows you to do more than simple 1:1 binding. I've written a new article explaining the interface. A behind the scenes look will follow shortly: http://www.litwindow.com/Library/Articles/rapidui_article_3.htm

Note that you can add correspondences directly to your data + validation code (no macros whatsoever).

While I don't like macros, I don't want to add them directly for bigger dialogues. It messes up my code. But your win32gui is interesting. Regards Hajo

you are missing my point. I want a higher level of abstraction.

win32gui is nice if you have a simple 1:1 binding for a struct - dialog scenario. But it will kill you if you have a frame window with a notebook as a client, several notebook pages with splitter windows, list boxes forms etc...

Really? Why?

I don't think I would like to do that using your 'save_dlg' setting. You need a way to break it up into small, manageable parcels.

And how is that not broken up into small parcels? (side-note: a dialog can contain sub-dialogs, each subdialog showing small pieces of information)

The Lit Window Library (http://www.litwindow.com/library) also lets you specify complex bindings that evaluate C++ expressions:

Frame.Title = "Headline: " + myStruct.m_title

Really? That's very unflexible if you ask me. You see everything as scripting. In fact, I see very little as scripting. You should note that you lose a lot of C++'s power if you switch to scrpting. And just for fun, you can accomplish the above using save_dlg, very easy: std::string headline(const your_struct & val) { return "Headline: " + val.m_title; } When creating the corresp. class, simply say: add_corresp( &headline, ID_whatever_field);

The data abstraction layer requires some macros, which btw are using templates and are type save, but allows you to do more than simple 1:1 binding.

Show me real examples where this makes sense. And let me repeat: - the 1:1 is a current limitation - you can work around it. And more to the point, where do you do validation? I don't see it anywhere in code. 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

John Torjo wrote:

Hajo Kirchhoff wrote:

...

I've written a new article explaining the interface. A behind the scenes look will follow shortly:

http://www.litwindow.com/Library/Articles/rapidui_article_3.htm

This sounds very nice in theory...

This is not a theory. Download the project, build it and try it yourself.

... But, please implement this: A dialog with - two edit boxes (width and height) - a check box (maintain_ratio)

If maintain_ratio is checked, whatever is typed on width is synchronized with height, and vice versa (they preserve the original ratio).

If maintain_ration is not checked, witdh and height can be modified independent of each-other.

This exists today in version 0.3.1: // please unwrap these lines BEGIN_RULES(dialog) RULE("eb_height.value", if_else(make_expr<bool>("cb_maintain_ratio.value"), make_expr<wxString>("eb_width.value"), make_expr<wxString>("eb_height.value")) RULE("eb_width.value", if_else(make_expr<bool>("cb_maintain_ratio.value"), make_expr<wxString>("eb_height.value"), make_expr<wxString>("eb_width.value")) END_RULES() It looks complicated because I am using C++ templates to specify rules that are lazily linked and evaluated only when a widget or data element changes its value. As the parser and named rules will be implemented next, the following will work next year... rule_editboxes { eb_height.value <=> eb_width.value // two way rule } rule_editboxes.enabled = cb_maintain_ratio.value The first rule links the edit boxes. The second rule enables the first rule when the checkbox is checked and disables when it is not checked. I don't have the time to write the example you suggest now, although it is a nice example. But perhaps the other two samples I've written already will suffice. Contained in the project (http://www.litwindow.com/library) you will find... The generic sample has a radiobox and an editcontrol. Whenever you change the radiobox, the value in the editcontrol gets updated and vice versa. The RssReader sample links a couple of listboxes and an html window together. When the user changes the selection of the rss channels list box, the headlines list box is updated automatically. When the user selects a different headline, the news item html window is updated automatically. Rules are headlines_listbox.items = channels_listbox.current.m_headlines newsitem_htmlwin.page = headlines_listbox.current.m_page Regards and thanks for sharing your thoughts. Hajo Kirchhoff http://www.litwindow.com/library