Subject | RE: [IBO] IBX-IBO conversion |
---|---|
Author | Helen Borrie |
Post date | 2002-10-03T10:01:57Z |
At 07:13 PM 03-10-02 +1000, you wrote:
you are opting not to use the native IBO controls, which link to the
TIB_Datasource and the TIB_* data access components.
through a TIB_Datasource. If you have made up your mind to use the TIBO*
data access, then it makes absolute sense to stick with your TDBGrid subclass.
QuickReports - unlike IBX, they are completely out-of-the-box compatible
with QR.
If you decide to go the TIB_* way (and it is well worth the effort), you
can link a TIBOQuery to your IB_Connection object (be it a TIB_Connection
or a TIB_Database) and use that quite happily with QR. I do it all the
time, being a horrible old conservative where reports are concerned (I have
some good custom QR subclasses that I don't want to waste!)
characteristics in either direction, using AssignSQLWithSearch. However,
the main value of this is to pass the current state of the powerful native
IB search to a TDatasource-compatible component set (such as QR), rather
than the other way. A native IBO dataset really doesn't have much (or
anything) to gain by borrowing characteristics from a
TDatasource-compatible one.
Helen
>Helen,No. By choosing the TDatasource-compatible(TIBO*) data access components,
>you've got me interested...
>I have an application which is about ready to go - based on IBX but I'm
>having reservations... thus my query
>I notice, though, that IBO also has many visual components, e.g I have
>already subclassed the DBGrid but IBO also has one and I fear that not using
>the IBO grid would also put me at a disadvantage. Is this correct?
you are opting not to use the native IBO controls, which link to the
TIB_Datasource and the TIB_* data access components.
>Would IThere is no IBOGrid. There is TIB_Grid which requires linking to TIB_Query
>be advised to convert all my code to IBO related controls, and therfore
>subclass from the IBOGrid for my purposes?
through a TIB_Datasource. If you have made up your mind to use the TIBO*
data access, then it makes absolute sense to stick with your TDBGrid subclass.
>Also, I imagine that I can still use the IBX stuff for Quickreports e.g.No, DON'T mix IBX data access with IBO. Use the TIBO* components for
>where it would not work (possibly) with non descendants of TDataset?
QuickReports - unlike IBX, they are completely out-of-the-box compatible
with QR.
If you decide to go the TIB_* way (and it is well worth the effort), you
can link a TIBOQuery to your IB_Connection object (be it a TIB_Connection
or a TIB_Database) and use that quite happily with QR. I do it all the
time, being a horrible old conservative where reports are concerned (I have
some good custom QR subclasses that I don't want to waste!)
>I thinkYou can assign the current SQL statement along with its current search
>I've seen some king of assignment from IBOQuery to other Query components.
>Is this correct?
characteristics in either direction, using AssignSQLWithSearch. However,
the main value of this is to pass the current state of the powerful native
IB search to a TDatasource-compatible component set (such as QR), rather
than the other way. A native IBO dataset really doesn't have much (or
anything) to gain by borrowing characteristics from a
TDatasource-compatible one.
Helen