Subject | RE: [IBO] TDataSet vs. Native |
---|---|
Author | Kaputnik |
Post date | 2001-01-05T23:47:31Z |
Hi....
well, the IBO Native components are not only a carry over but more than a
good replacement....
Well, where to start....
First, the IB_xxx stuff has no persistent fields, but almost every settings
stored in the dataset itself. That has some drawbacks, but much more
advantages...This makes configuring data-aware components a no-brainer.
Simply assign the field and datasource, and everything else is configured.
The grid itself is fabulous.....headers indicate possoble sorting-orders and
clocking them resorts the query, without closing and repoening it....also,
switching datasets at runtime fo the grid is no problem...as all settings
are stored in the dataset, the grid configueres itself accordingly.
Also, the Grid accepts in-place-editors that you simply drop into the grid.
The Lookup-components are also a hit...they have not simple dropdowns, but
complete picklists with several columns with headers and are
sortable(!!)...you'll need 3rd-parties to do that with the TDataset-classes
which almost cost as much as IBO itself :-))
Added to this the state-awareness of the components with changing colors
(colors indicate edit, browse or search-mode), and the complete built in
search-capabilities with almost complete QBE-syntax, you have a great
framework to build cool and user-friendly applications.
Also, there is support for incremental searching built in right into the
Grid, but also there are seperate controls to do this.
Also, the Datasources of IBO use a messaging-subsystem to announce, when any
components linked to them are focussed....and the IBO-bars can receive this
focus, making e.g. MDI-apps with centralized bars a breeze....if one form is
selected, the bars are focussing on its datasource without code....and there
is not oly a navigation-bar, but 6+2 bars, all capable of beeing included in
standard-toolbars.
There is much more to the native components, but I hope, you got a first
impression.
CU, Kaputnik
(Nick Josipovic)
nick@... <mailto:nick@...>
kap@... <mailto:kap@...>
-----------------------------------------------------------------------
superior Client/Server programming:
www.IBObjects.com <http://www.ibobjects.com/>
a nice Tool for Interbase:
www.InterbaseWorkbench.com <http://www.InterbaseWorkbench.com>
well, the IBO Native components are not only a carry over but more than a
good replacement....
Well, where to start....
First, the IB_xxx stuff has no persistent fields, but almost every settings
stored in the dataset itself. That has some drawbacks, but much more
advantages...This makes configuring data-aware components a no-brainer.
Simply assign the field and datasource, and everything else is configured.
The grid itself is fabulous.....headers indicate possoble sorting-orders and
clocking them resorts the query, without closing and repoening it....also,
switching datasets at runtime fo the grid is no problem...as all settings
are stored in the dataset, the grid configueres itself accordingly.
Also, the Grid accepts in-place-editors that you simply drop into the grid.
The Lookup-components are also a hit...they have not simple dropdowns, but
complete picklists with several columns with headers and are
sortable(!!)...you'll need 3rd-parties to do that with the TDataset-classes
which almost cost as much as IBO itself :-))
Added to this the state-awareness of the components with changing colors
(colors indicate edit, browse or search-mode), and the complete built in
search-capabilities with almost complete QBE-syntax, you have a great
framework to build cool and user-friendly applications.
Also, there is support for incremental searching built in right into the
Grid, but also there are seperate controls to do this.
Also, the Datasources of IBO use a messaging-subsystem to announce, when any
components linked to them are focussed....and the IBO-bars can receive this
focus, making e.g. MDI-apps with centralized bars a breeze....if one form is
selected, the bars are focussing on its datasource without code....and there
is not oly a navigation-bar, but 6+2 bars, all capable of beeing included in
standard-toolbars.
There is much more to the native components, but I hope, you got a first
impression.
CU, Kaputnik
(Nick Josipovic)
nick@... <mailto:nick@...>
kap@... <mailto:kap@...>
-----------------------------------------------------------------------
superior Client/Server programming:
www.IBObjects.com <http://www.ibobjects.com/>
a nice Tool for Interbase:
www.InterbaseWorkbench.com <http://www.InterbaseWorkbench.com>
> -----Original Message-----
> From: Chris Landowski [mailto:chrisl@...]
> Sent: Friday, January 05, 2001 11:46 PM
> To: ibobjects@egroups.com
> Subject: [IBO] TDataSet vs. Native
>
>
> I noticed on this newsgroup, that most people prefer to use the
> Native IBO components over the TDataSet versions and was
> wondering why ? I use TIB_DSQL, TIB_Cursor and TIB_Script pretty
> regularly, but for binding data aware components I typically use
> TIBOQuery. My primary reason for this, is to simplify the
> conversion from the BDE, while still being able to use the
> existing data aware components I have developed over the years.
>
> When I first purchased IBO, I figured the native components were
> simply a carry over from the days prior to Borland unhooking
> TDataSet from the BDE. Apparently, this is not the case.
>
> I just read a post where someone was going to convert 150 forms
> over to all native components. This seems like a daunting task
> and was wondering if all this effort is really worth while, since
> the app I am converting has somewhere around 300 forms ? Am I
> missing something by not using TIB_Query ? Is performance
> noticeably better ?
>
> Chris Landowski
> Dynamic Software Solutions
>
>
> [Non-text portions of this message have been removed]
>
>
>
>