From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-29 16:01:31
* David Abrahams <dave_at_[hidden]> [2004-12-29 13:52]:
> Reece Dunn wrote:
> >> With Carbon, I think you just use native controls.
> >> With Win32 GDI you roll your own controls.
> > I think that this is not the right approach. You should only roll your
> > own controls when that control isn't supported by the target OS. The
> > Win32 GDI and Win32 controls/common controls are different things.
> Not different enough, IIUC. They're both subject to the same (shared)
> constraint on maximum number of window handles. To make a windows GUI
> framework scalable it must provide for that. Not every widget on the
> screen can afford to be an OS control or window, even when there are
> appropriate built-ins (consider a grid of spreadsheet cells). One
> approach might be to make them "ephemeral," i.e. conjure up the actual
> OS thingy only when you need to draw or process clicks there and then
> throw it away immediately or soon.
In a more complicated UI, native controls are going to fail the
Materialization is a good strategy, but it doesn't address the
problem of rendering. An OS rendered control taking part in the
window heirarchy of the OS, displayed within a client area that
has an application defined z-axis with overlayed (oh, can I
borrow a term?) thingies, well that OS native control stomps all
over the application rendering.
The application developer is left to roll their own, so what's
the library for anyway? Dialog boxes on the one hand,
do-it-yourself on the other? Sound's like MFC to me.
-- Alan Gutierrez - alan_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk