Subject | [IBO] Re: More Scroll Questions... (More Info) |
---|---|
Author | Eric Handbury |
Post date | 2002-10-16T00:19:41Z |
--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:
of IBO... a doctor is the end-user of a stethoscope. But we digress.
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.
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.
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
refresh.
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.
>Every product has a end-user... I, as a developer, am the end-user
> 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).
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 theNo, you are not rude... I like blunt, to-the-point discussions.
> 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.
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 hasTo be blunt (again!?)... IBO must change. I am not talking about a
> 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 ;-)
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 placeNot true. This is not a grid-thing. A user of my program would be
> 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.
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
refresh.
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.