""Jason Wharton"" <jwharton@...> skrev i melding
news:b481ie$fpo$1@......

> > Now I wonder: Why isn't IBO help file complete, or anything *near*
> complete?
>
> Because I have not completed it yet. I acknowledge there is more work that
> can be done in it and you are invited to take part in the generation of
> them. Is all that is necessary is you use the tags in the source code that
> my help file generation tool reads and constructs the help file from. Let

me

> know if you are interested. I always appreciate what people are committed

to

> behind their complaints.

I believe I'm not quite there. It's about time, and it's about still not
having the overall picture.

> > I mean, this is a commercial product, right ?
>
> Not exactly. It is a trustware product which has a commercial aspect to it
> but it also has an open-source'ish aspect to it as well. The vast majority
> of people who use IBO do so for free, at least initially. Thus, I feel it

is

> fine if I ask for those out in the community who can and have the drive to
> make some investment in IBO by contributing to it as they are able.

I'd say that a packet price of $395 makes it "commercial". I can't see
anything written that indicates I should plee for a free license. I am a
professional, and the purpose is all commercial. In fact, I just invoiced
the customer a number of $$ spent to convert an application from BDE to IBO.

> > 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.
>
> This is a general rule to apply. If you aren't sure what it does, ignore

it.

...it's hard to ignore a property just because it doesn't have a complete
help entry.

> Property default values are designed to have normal industry standard
> behavior. If you are confronting challenges on a creativity basis, like

how

> do I get IBO to do this in the most efficient way, that's when we invite

you

> to come to this list and partake of the best kind of documentation one

could

> wish for. Generous experts willing to share their insights and skills.

This is fine, and I both ask and answer questions in forums every day. What
I usually *don't* do, is asking ten-folds of questions regarding this or
that property. The reason is, usually a quick look into the help file or
sources is all that's needed. This process has proved to be patience
challenging with IBO. One example (which, oddly enough, was one of the most
troublesome things about moving to Direct Oracle Access, too) is the SQLType
constants - as they are not typed, there is absolutely no way to perform a
quick lookup. I'll have to search IBO sources for ".SQLType", and go to one
serch hit, just to Ctrl-click the SQLType constant. "SQLType" has no useful
entry in help file. Why not use typed values ?

> I also highly recommend you take some time in the sample applications.

They

> are a living example of how an IBO application can be put together. Agreed
> they aren't ideal for some things they are effective at demonstrating all

of

> the basic and core usages. This is the next best type of assistance when
> looking to give your software generation creativity some additional

fluency.

Now, there is *one* thing a sample application doesn't offer: Insight about
property settings. Or - at least - it's extremely hard to get the overall
picture. That's not connected to IBO specifically, it goes for the Delphi
concept. It just means sample apps must be built in a slightly different way
to be instructive. Whenever I select a TIB_Query in a sample application,
How do I know what values are set to Non-default ? How do I get a quick view
of what's written in TStrings - type properties ? One possibility is
shifting to textual representation of .dfm file - but there is still no 100%
sure way of knowing what was default and what was actually *designed* so in
IDE.
An example: I tried to make TIB_LookupCombo work, and I studied the sample
app for an hour or so trying to locate the difference between my code and
the sample app's. finally I had tried so many different combinations of
property settings, I still wasn't 100% sure I knew what actually made it
work.

> Now, if you are comfortable with all of the above strategies then the help
> file is probably filled with useful information where these are
> insufficient. Put another way, I've put in the help file that which I
> generally expect to find. I don't use them all that much when I am using
> others components. I just go to their sources, the best documentation one
> could ask for.

I've been spending a few hours with the help file, some time with the sample
apps and tenfolds reading code.
That's the reason why I'd like the source to be more readable. But as a
general rule - if you wonder what some property is about, the help file
should definately provide relevant info. Otherwise the generalized component
concept isn't worth much. AMOF is, it would be easier if there were no
components, as setting properties would have to be clearly done within .pas
code files.

Jason, I'm convinced that IBO components are indeed good. Lack of
documentation & somewhat obscured sources reduces the overall usefullness a
lot, though. Well, er...at least - the overall economy. Remember - a
programmer doesn't want to go further than what she or he *needs* to go. The
bigger a difference between IBO and other database access components, the
higher the costs of implementing them.
At a daily basis, I'm using IBO, BDE access, Direct Oracle Access, DataSnap
and an OO database framework. For reporting - QuickReports, Report Builder
and Crystal Reports. I'd like them to be as similar as possible rather than
100% optimized. *If* one has to choose.
Somehow I feel like the optimization issues has had too much attention
within IBO. There is much "optimization automation" going on under the hood,
and I'm having a real hard time trying to get rid of some of it. For
instance, making the components stop asking for a complete list of tables.
Whenever that happens, a few seconds delay is introduced. As I interpret the
code, it's part of a shcema cacheing mechanism which will eventually lead to
better performance. I just don't *want* this 2 seconds delay aimed at making
the application quicker afterwards. Shouldn't one be able to avoid such
"investments" when it is not desired ?
..and the transactions stuff - once I left the TIBODatabase / TIBODataset
components, I had a few days of work trying to make sure all objects were
sharing the proper session/connection objects. The "smart" transaction
handling makes it even harder to make it work.


--
Regards,

Bj�rge S�ther
bjorge@haha_itte.no