Subject Plans for IBO Help file ....?
Author Bjørge Sæther
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'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.

Control how the default drawing of Cell text is performed.

Applies to

property DrawCellTextOptions;


...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

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.


Bj�rge S�ther