From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-30 12:22:32
Jody Hagins wrote:
> On Thu, 30 Dec 2004 08:25:51 +0000
> Reece Dunn <msclrhd_at_[hidden]> wrote:
>>How do you intend on writing *UI objects* - frames, widgets, layout
>>managers, etc. - that can interact with each other, be moved and
>>process events correctly without sharing a common *ui::object* base?
> No one should confuse me with a GUI expert, so take what I say with a
> grain of salt w.r.t. GUI development. However, I want to respond to
> this question, as it really does not have anything to do with GUIs.
> I assume you are talking about having a common base class with virtual
> functions for common tasks. This is certainly one way of doing it, and
> not being a GUI person, I can not comment on the "correctness" of such a
> proposal - it may well be the best methodology.
> However, to answer your question, you can certainly accomplish the same
> thing (i.e., "write UI objects that can interact with each other")
> without a common inheritance hierarchy.
> What kinds of interaction between the objects requires inheriting from a
> common base class, as opposed to using Boost.Bind, Boost.Function, and
Take a layout manager, for example. A layout manager hosts a series of
UI objects (these may themselves be layout managers). The layout manager
requests the size of the object and moves an object to the new position.
This behaviour needs to be common between the UI objects in order to
allow the generic calculations.
I am not sure what the best approach is and am working on revising the
implementation I have to accommodate lightweight objects. My focus is
towards native objects, whereas Alan is focused on lightweight objects.
Using a template along the lines of:
ui::object< ui::native, ui::button > btn( ... );
how do you create the object at the constructor, i.e. not using the
Create/OnCreate structure of Win32/MFC/WTL.
As for on-demand creation, this is dependant on the data model being
used. For example, the grid UI object uses a cell_provider:
virtual std::string get_data( long r, long c ) const = 0;
virtual bool is_editable( long r, long c ) const
virtual ui::object * get_object( long r, long c ) const
where, if get_object( r, c ) returns 0, the cell is a text cell with the
value get_data( r, c ), otherwise it is rendered using the UI object
returned. Here, a text edit control is only needed when the cell is
editable and the user interaction signifies an edit action. The grid or
table control will maintain the visible cells and dispose of the cell
data/object once the cell goes out of visibility.
Here is another example of using a common base - how would you do this
if they were separate? Granted for a table, you could have a tuple or
for a grid you could restrict it to be a single UI object type
(textfield, radio button, etc), but this complicates matters.
BTW, I make use of Boost.Signal and Boost.Bind for event handling as
these are necessary for the flexibility that they provide.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk