> -----Original Message-----
> From: Lester Caine [mailto:lester@...]
> Sent: Tuesday, January 14, 2003 9:44 AM
> > I agree, that we shouldn't necessarily need the detail dataset to
> > fire *open and *close events when the master scrolls, but the detail
> > dataset's afterscroll event _does_ need to fire. That would be
> a bug, IMHO.
>
> If the detail's dataset has scrolled? Which may not be the
> case just as there may not need to be an open and close.
>
> I think we are falling into the trap that MS created. There
> are many ways to do something, and none of them are
> particularly 'right'. And not all of the ways achieve the
> same result.
>
> If there are conditions where AfterScroll should fire, but
> does not, then that is what Jason is asking for an example
> of. I don't use AfterScroll much myself, prefering the
> DataSource - OnDataChange which I do know only fires when
> the source data has changed, and allows me to update
> secondary stuff reliably.

Point well put, Lester. Actually, I was only _attempting_ to lend support
to
the idea that afterscroll on a detail dataset when the master changes is
more
"standard"/"expected" behavior than *open/*close events. I, too, don't
often use the afterscroll events for anything except interface issues ( such
as special display
effects like different font colors depending on a field value, etc ).
However, like Alan, I guess I have become accustomed to a certain expected
behavior.

As you correctly state, the idea of "standard" or "expected" is relative,
since
I can think of numerous real-life ways you could have a single detail record
linked
to two separate master records.

> So where is the correct place <g>

I guess that's the 6 million dollar question that Jason, being the creative
genius behind
these components, has to decide. - have fun, Jason! @;-)

Brian