--- Brock Peabody <[EMAIL PROTECTED]>
wrote:
> > Anyway I think I got the basic idea. The idea is
> that
> > the GUI elements are classes defined on top of a
> > pImpl. Someone else creates the pImpl object and
> > passes it to the GUI elements classes. The GUI
> > elements then call pImpl methods do the real job.
> > Did I get it right?
>
> Yes, and you're confused because I left part out.
> Sorry!
>
I personally don't see any significant benefits in
using pImpl here but there are lot of disadvantages.
For example you would have to make sure that all pImpl
functions use a set predefined data types. It means
that the pImpl functions will have to convert the data
between native format and pImpl.
In the case of ImplTraits you can use native data
types directly.
Example:
class win32
{
typedef WHND WinHnd;
};
template <typename ImplTraits>
class window
{
public:
ImplTraits::WinHnd m_hnd;
...
};
The bad list about pImpl goes on an on.
[...]
> They would typically all be part of (or a sub part
> of) the same gui
> object.
My personal preference is to have two kinds of
groupings.
1. Visual/behaviour grouping
2. Data groping.
Using the first the first option, you can group GUI
elements into one presentation group. The visual
grouping would be managed by gui managers.
The second option is similar to the MFC document/view
architecture. You could connect a data item in a list
control to an edit box (even in different dialogs) on
the data level. If one control changes the data, all
connected controls get updated automatically. This
kind of grouping will have to be independent from the
gui managers.
Eugene
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
