Well, actually I was playing devils advocate. We are working on
requirements submitted to us. Exchanging all our memos is a MAJOR
job and would affect large part of system. We need to be as sure as
possible that A) we fulfill the requirement B) Don't introduce side
affects in the entire system C)Don't need to replace our queries.

Thanks for your reply. We'll work further based on the
recommendations.

--- In IBObjects@yahoogroups.com, Lester Caine <lester@l...> wrote:
> Harvey wrote:
>
> >>after much research I have utilised the RichView component. It's
> > very good
> >>but it is only useable with the non-native IBO query components.
> > This is how
> >>I use it. There's no problem mixing and matching between
datasets
> > which need
> >>the IB_ native and ones which need the IBO ones.
> >>That said - someone else here was indicating their interest in
> > creating a
> >>RichView version which is compatible with IB_ datasets. I would
> > really like
> >>that too. And the ultimate of ultimates would be Dimitri's zlib
on
> > the fly
> >>component incorporated into it... oh what a dream component that
> > would be.
> >
> > My conclusion after reading the messages is there is not yet
> > a "safe" and IB_ datasets compatible component. If this is
incorrect
> > please explain why.
>
> Why would you conclude that?
> We would all like the ultimate component, but every one we use now
has
> some sort of compromise.
> IB_RichEdit works fine, but is NOT a word processor, it IS a very
good
> memo editor.
> There is no mention of 'safe', using non IBO native components is
just
> as safe as native, and is VERY appropriate for some more powerful
> components ( TMS's planner is a very good example that I use with
IBO ).
> We use what is appropriate for the job, and if there is a large
demand
> for something it can be added, but given the amount of work
already
> invested in other 'non-IBO' components that IS the most logical
and save
> route!
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services