DynLayer IS the root component (that's what I've been trying to say)
Every widget needs the graphical functionality of a DynLayer, that's why it
IS the base object.
Ofcourse TComponent is Delphi only, because Windows internally probably
doesn't have anything like it.. just graphics functions to draw canvas's.
But that's what we're doing here as well, DynLayer is the canvas object to
do all "graphical" interface tricks (this is DHTML, not windows, so mostly
used for visual development of websites)
If you want a widget without any graphicall functionality then don't base if
on the DynLayer (never seen one, but it might happen).
But as it is now, all widgets will always function the same they always
have: moveTo, setSize, setHTML, etc,etc,etc
This makes creating widgets that interact with each other alot easier
because you don't have to check for these methods to be available, they are
simply available.. so take a toolbar widget, you can add ANY other widget on
it, without having to prepare them or checking there class type.
If you want your widgets using another model, go ahead but most (not all
though, but majority) people involved agreed that this was the way to do
widget inheriting: it's simple, short, and standard Javascript inheriting.
And I for one will stick to this way of widgets.. use your own model if you
like, just make sure there fully compatible.
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.dynamic-core.net
> No,
> Delphi TComponent (been reading about this because of the Kylix)
> is a basic
> component that wraps the calls to the API.
>
> I don't care if we make a TComponent or TWidget but I just perfer
> this over
> using the DynLayer itself.
>
> 8an
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
