Hi Paul

>
> > I'm simply saying that Next and Prior should not go beyond the ends
> > of the data.
>
> I don't know - I'm used to this behaviour and it suits me fine. Maybe
> because it's analogous to how iterators behave in C++. It just feels
> natural to me that if you're stepping through <something> in your
> code, your last step takes you beyond the last element. I also have
> lots of loops set up like this:
>
> for ( MyDataset->First(); ! MyDataset->Eof; MyDataset->Next() )
>
> The day Jason decides to change First and Next like you propose, these
> loops will still compile fine but they will become black holes: what
> goes in there never comes out again! :-)

I must admit I do not understand (or want to understand ;-)) C++ syntax -
but I cant see why leaving the row pointer at the last record when returning
eof would make any difference. The BDE did it OK - and at least that was
not the reason IT has ended up in a black hole :-)

>
> Now, if you say there should be two functions - say "NextRec" and
> "PriorRec" - that go to the next or prior record _if_ such a record
> exists, yes, those might come in handy, especially for code you write
> in response to user button clicks etc. In general, you don't want to
> bother the user with concepts like EOF, "beyond the end of data", and
> stuff like that.
>

Yeah - NextRec and PriorRec would suite me fine - if that was the nearest
solution that would not impact other things.

>

Regards
Paul

> Greetings,
> Paul Vinkenoog, beyond your wildest EOF

What a frightening thought ;-/