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

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.

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.


As for why a separate event? Two reasons:

1. I imagine that will be the easiest way to make the change

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
are other people out there using this code, their applications
must be considered. I've had my own applications broken through
unconsidered and unnecessary change (quite recently in fact) and
it is no fun!

--
Geoff Worboys
Telesis Computing