Subject Re: [VirtualTreeview] Re: IB_VTree
Author Paul Gallagher
The beauty of this project is that the sources to VirtualTree and the
IB_TreeView are available free to all. The source of IBO is also free for
non commercial uses. If anyone needs to make changes they can. If someone
makes a change to VirtualTree that will likely be useful to others then Mike
can permanently add it to the source. Jason does this all the time with IBO,
and in fact he seems to encourage it.

Like I mentioned earlier, the basic framework connectivity of porting
Virtual Tree to IBO is done. In my opinion, that was the hard part. Now it's
just a matter of someone modifying the source to IB_VTree.pas to add
functionality. If someone desires a different datastructure, then there can
be a published property called StructureType added.

I'm not sure who is going to maintain the code for the IB_VTree. If Jason or
Mike don't want to deal with including it in their packages, then I can
setup a webpage where it can be downloaded.

Paul Gallagher

----- Original Message -----
From: "Mike Lischke" <public@...>
To: <>
Sent: Thursday, February 08, 2001 3:30 AM
Subject: RE: [VirtualTreeview] Re: IB_VTree

> Hi Lester,
> > There are two schools of thought running at the moment.
> >
> > A/ A component must do everthing for everyone.
> >
> > B/ The most efficient component is designed for its job only.
> >
> > IB_VTree is a type B component, just as IBObjects is a type B
> > database interface. Those of us who do not want the cumbersome overheads
> of
> > ODBC, ADO etc. Like the simplicity, and the power and speed this
> > provides.
> Well, I think the solution is (as so often) somewhere in the middle. One
> component for all is of course not possible, while creating every time a
> component for similar but slightly different tasks is not acceptable.
> my wish to have a control which covers, say, 80% of the likely cases and
> special editions for the rest.
> Ciao, Mike
> To unsubscribe from this group, send an email to: