Subject [IBO] Re: More Scroll Questions... (More Info)
Author Eric Handbury
--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:
> You are not an end-user, at least I hope not. Neither IBO nor
> Delphi are designed for end users. You are, presumably, a
> programmer, developer, software architect, software engineer etc
> (choose the description of your choice).

Every product has a end-user... I, as a developer, am the end-user
of IBO... a doctor is the end-user of a stethoscope. But we digress.

> I hope I dont sound too rude, but the "I'm not interested in the
> details" does not cut much ice with me. Its your job to be
> interested in the details. You are obviously already aware of
> this, from the detailed analysis you have already performed.

No, you are not rude... I like blunt, to-the-point discussions.
What I should have said is that the operations that IBO performs to
do its job should not be visible to me. What I do internally when a
customer adds a service using my program should be no concern to them.

> When it comes to the Scroll events, I do understand how it has
> has not met your expectations. What I have tried to explain is
> why it behaves the way it does and that this means it cannot be
> simply changed to meet your expectations. (Of course Jason may
> cut me off at the knees and fix it tomorrow ;-)

To be blunt (again!?)... IBO must change. I am not talking about a
4_2Hi to 4_2Hj change; this is possibly a major change. I could be
wrong, but I can imagine that this intertwining relationship between
the IBO internals and its published interface goes well beyond just
the Scroll events.
To me, the separation of IBO internal operations from its published
interface would be a good (long-term) thing to do and would allow
future changes to its internals to be done more easily. Its like OO-
programming: where the interface is separate from the implementation.

> If it were not for the grid interactions you could easily place
> your code in a more appropriate place. One area where a "fix"
> could be applied more easily than with Scroll events is to make
> it easier to detect row changes coming from a grid.

Not true. This is not a grid-thing. A user of my program would be
staring at some edit-controls on a Tabsheet, would edit some data,
would hit the 'Apply' button, would edit some more data, would say
Oooops, would hit the 'Cancel' button, and suddenly, all their data
would disappear because IBO fired the BeforeScroll event on its data

Believe me, Geoff, I am desperately trying to find a workaround,
but have been unable to do so upto this point. The BeforeScroll event
is the most obvious place to put this code.