> 1) Why is only the SysAfterScroll called? Why not BeforeScroll?

Because the master dataset is scrolling back to an existing record
(or Bof/Eof) when the new record is no longer present.

As for BeforeScroll - not sure whether it should happen or not.
Its an interesting thought, the possible problem is that
BeforeScroll usually indicates that you can stop the scroll from
occuring - and that should probably not be permitted when cancelling
an insert.

> 2) My biggest problem... Why is the Master current row adjusted
> (and therefore the Scroll events fired) before the
> Master.AfterCancel is fired?

As above.

> 7) The Master.AfterScroll is fired. (incorrect)
> 8) The Master.State value within the AfterScroll is still
> dssInsert which screws-up my logic.

Hmmm...

AfterScroll is correct.

Whether the event should occur before or after the state change
away from dssInsert is open to debate. It could be argued that
the information is helpful to tell the program the reason for
the scroll event. Indeed it is even possible that code exists
that depends on this feature (ie. need to be very careful about
changing the order of events).

It may help if you tell us what you are trying to achieve. Perhaps
we can offer alternatives (for example, I tie various state checking
to the transaction rather than a master dataset - but it will depend
on what you are wanting to achieve).


PS. Its good to see someone doing a detailed analysis of an issue
before posting. It makes it so much easier to understand what you
are seeing and to try and help

--
Geoff Worboys
Telesis Computing