--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:

> > That's right, not only must the interface must be separated from
> > the implementation (which is not the case with IBO) but the
> > application should adhere to the MVC model where the Control of
> > data is separated from the View.
>
> Back up just a moment. Just because you have found an instance
> where events are not giving you what you expect does not mean that
> IBO is violating any great rules.

I have always been a person who tells it like it is, and the bottom
line is that IBO currently allows implementation details or internal
operations to filter into its published interface. The Scroll events
is an example of this. This is all I have said. I have not denigrated
the product or the people involved in it. Just stated the facts
(ma'am).
Having said that, I think IBO is a first-rate product and it is a
critical part of an application which (I hope) will be my livelihood
for the next few years.

> Please remember that IBO has been around a long time and has a great
> many users. This is not to say it is perfect, I dont believe that
> for a moment. But it should give you pause to consider;
>
> Am I doing something unusual here? If you are getting such an
> insurmountable problem then it must be reasonably unusual
> considering the large number of users that have gotten by
> without it.

I had an earlier insidious IBO problem where both Insert and Update
triggers were being fired on a single Detail Insert and I was very
surprised that this problem hadn't surfaced a million years ago. But
it hadn't.

>
> If I am doing something unusual is it correct? (Your call.)
>
> Is there a better (not necessarily easier/obvious) way that
> this could be done?
>
> There are lots of things that IBO does not do the way I want. This
> is why I have my own library of derivations and extensions that
> force both IBO and VCL to work my way.
>
> Or to put it another way. Just because something does not work
> the way you want it to does not make it broken.

It has nothing to do with 'what I want it to do'. It's broken
because the event fires on an internal IBO operation as opposed to
limiting itself to only 'user-initiated' events and this is plain
wrong. And to mimic what you say later on... 'This last point is
something I've reiterated in postings quite a bit recently but it
does not seem to be getting through'.

> As for why a separate event? Two reasons:
>
> 1. I imagine that will be the easiest way to make the change

But this doesn't make sense... Jason would be leaving the Scroll
event broken, but create a new correct event.

> 2. Negate the chance of breaking existing applications.
>
> This last point is something I've reiterated in postings quite a
> bit recently but it does not seem to be getting through. There

It's not getting through because I don't agree with it. I can't
think of a situation where a user would want to do some actions based
on IBO incorrectly firing a Scroll event. And if people are using it
in this situation then 1) they should not be since they are dependent
on IBO internals and 2) their program may be operating incorrectly
and they don't know it.

Anyway, Geoff, its been a very good discussion and I have learned
alot about the IBO internals and I think I should wait on Jason to
decide what he wants to do.