Starting with IBO is not very easy, but once you get used to it, you would
not want to change. The help file is not very descriptive sometimes, but you
can always search and ask this newsgroup to find very valuable answers.

I think that Jason's time and skills should be realized more in further
development than rewriting and merging the imp and int files. This is not a
big problem for me. AFAIK this architecture is very handy when developing
new native IB_ components and allows easy reusing of existing code (you can
"learn" other component to behave in the IB_ native way by including the imp
and int file appropriately).
Ales

> -----Original Message-----
> From: Bjxrge Sfther [mailto:bjorge@...]
> Sent: Tuesday, March 04, 2003 1:02 PM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Plans for IBO Help file ....?
>
>
> Hi !
>
> First of all, sorry for not answering messages.
> My OE News reader crashes all the time, allowing for only
> smaller messages.
> It is of course possible to work in another editor, but it
> makse message
> writing awkward...so..I'll get back.
>
> Now I wonder: Why isn't IBO help file complete, or anything
> *near* complete
> ?
> I mean, this is a commercial product, right ? I don't know
> how many extra
> hours I've been spending because of the poor help file, and
> someone does
> actually pay for this. Either me & my family or my customers.
> And I don't mean *tutorials*, I mean *documentation*: "What does this
> property affect, and how ?" - and - when an explainatory text
> isn't easily
> written, an example or two.
>
> <snip>
> DrawCellTextOptions
> --------------------------------------
> Control how the default drawing of Cell text is performed.
>
> Applies to
> TIB_Grid
>
> property DrawCellTextOptions;
>
> </snip>
>
> ...loading code files with tags could be justified if it
> resulted in a good
> help system. Now I have relatively unreadable source files *and* a
> relatively useless help system.
> This has something to do with priorities. IBO is *loaded*
> with functionality
> (having a hard time to avoid some of it to be invoked), but
> the initial
> investment in starting to use IBO is tremendeous.
>
> Keeping BDE was never really an alternative, for reasons well known
> (Firebird, Borland stopping development, awkward
> installation). But I find
> it somewhat strange that I have now worked on conversion to
> IBO for some 5
> weeks, and I would *still* prefer the BDE version. Some things are
> definately quicker, but the large picture is *not* convincing. I still
> struggle with expremely poor performance caused by eccessive metadata
> access.
>
> Now, the conclusion:
> 1. The "generalized BDE concept" makes it hard to use the
> RDBMS for all what
> it's worth. I've experienced this with Oracle and with
> Interbase. BUT: The
> BDE components are in fact well designed (the *surface*, that
> is). Direct
> Oracle Access components could serve as an example of a
> successful RDBMS
> access component suite.
>
> 2. IBO introduces a lot of properties that obscure the
> overall picture by
> their lack of relevance. "IncSearchKeyInt" (time in ms before
> an incremental
> search is cleared) is not a relevant property of TIB_Query
> whatsoever. It
> belongs in "visual controls sphere". The components have
> generally been
> extended with functionality that belongs somwhere else. What
> has color to do
> with a Session ? (yes, I know the link, but such kind of
> links are to be
> avoided for the sake of clarity).
>
> 3. A result of this is a desperate need of a good
> documentation. Which -
> unfortunately - isn't there.
>
> 4. Division of files into .pas, .int & .int makes the code
> hard to read.
> Additionally, the introduction of a help system that creates
> tags makes
> portions *totally* unreadable.
>
> 5. Writing components is hard, and it hasn't paid off as much as the
> community of developers have expected. There are a few things
> that make most
> of things I write of little use as generalized components.
> Mostly the fact
> that special needs typically are too heavily reflected while there are
> others totally missing. IBO suffers from such downsides.
>
> I am very sorry about this, especially as I have burned the
> bridges. I just
> can't tell my customer "sorry, I made a mistake. IBO will
> cost you $$$$, and
> I can't promise much benefits".
>
> I am concidering two options: Testing out the other (few, that is)
> alternatives or rewriting IBO to make it work. I believe the latter is
> faster than getting the feel for how it's actually meant to
> be used. First
> steps would be putting the .imp and .int files back where
> they belong, and
> to remove the horrible help tag scribble. Next - to get in control of
> metadata retrieval.
>
> And to Helen Borrie:
> Please don't tell me I do not understand the core of Database
> programming,
> Interbase or IBO. This posting isn't about what IBO
> components are capable
> of, nor is it the judgement of an experienced IBO programmer. It's the
> complaints from a person who chose a component suite not very
> well suited
> for general DB access.
>
>
> --
> Regards,
>
> Bjrrge Scther
> bjorge@haha_itte.no
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/PhFolB/TM
> --------------------------------------------------------------
> -------~->
>
> ______________________________________________________________
> _____________
> IB Objects - direct, complete, custom connectivity to
> Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ______________________________________________________________
> _____________
> http://www.ibobjects.com - your IBO community resource for
> Tech Info papers,
> keyword-searchable FAQ, community code contributions and more
> !
>
> Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/