Hi Paul

I have to agree that Lester has made the the most convincing arguement for
the IBO way - so to my mind the solution would be to to have NextRec and
PriorRec functions that would behave like the navbar.

I'm exhausted now - so I'm going for a lie down.

Regards
Paul

> Hi Paul,
>
> >> To me, the IBO way is much, much cleaner and more consistent.
> >
> > I still dont agree :-)
> >
> > Firstly - 'While not eof do next' would not be broken.
>
> That's right. If you loop through the dataset using Next/Prior and
> testing for Eof/Bof, TDataset and TIB_Dataset behave the same.
>
> > In fact IBO only gets away with this working because the loop exits
> > after the last next and does not attemp to process the record last
> > pointed to.
>
> Both TDataset and IBO get away with it because you exit the loop
> on Eof. IBO gets away from referring to a record that isn't there,
> TDataset gets away from processing the last record more than once.
> I think IBO is safer here, because if you make the mistake of exiting
> too late, you'll either get an error or (in the case of the AsSomeType
> properties) the field values are nil.
> In TDataset, the last record would be processed more than once, which
> may or may not be harmful depending on what you are doing. (But if you
> are summing values for instance, such an error may go unnoticed for a
> long time.)
>
> Anyway, I wouldn't call this "getting away with it". Suppose you have
> this loop (with Strl a TStringList):
>
> for i := 0 to Strl.Count - 1 do
> begin
> <do something with Strl.Strings[ i ]>
> end;
>
> Do you feel you "get away with it" because you stop just short of
> attempting to access Strl.Strings[ Strl.Count ] ?
>
>
> > Nextly - I dont see EOF as a state, and dont see why it should be a
> > state. To me EOF is a flag that says 'your last attempt at next
> > failed because you are at the end of the dataset'.
>
> Fair enough. If that's what you want, TDataset.Eof does the perfect
> job for you.
>
> > Also the current 'state', meaning pointing to an invalid record past
> > the end of the dataset, does not distinguish between an empty
> > dataset and a full one gone off the end.
>
> No, but that's consistent. If there are zero records and you try to do
> access the first one, you _are_ past the end. Same as with the
> TStringList loop.
>
> > Perhaps I should propose that the current functions are renamed BBF
> > (Before Beginning of File) and PEF (Past End of File) and modify the
> > BOF and EOF source using the code in the NavBar ;-)
>
> I agree that the name Eof is ambiguous. You can interpret it as "the
> outermost border of the dataset", i.e. just beyond the last record,
> or as "at the last record", just as you consider the end of a book to
> be on the last page, or maybe even the back cover, but not past the
> back cover.
>
> Bof is even worse (to me), because I do consider the first record to
> be the beginning of the set. Probably I'm conditioned by all those
> loops where you start at the beginning (valid unless equal to end) but
> you bail out just before the end (which is an invalid position).
>
> But then, TDataset.Eof is also a misnomer, because you can't use it to
> test if you are on the last record. Like you said, it's now a flag to
> indicate that your _attempt_ to go past the last record failed. (And
> not even that, because if you call Last in your code, you aren't asking
> to go past the last record; yet TDataset.Eof becomes true.)
>
>
> OK, no use trying to convince each other any further! It all depends
> on how you look at things. But I liked this thread because it's good
> to see that what's perfectly natural and logical for one person may
> not be that for someone else - without either of them being "wrong".
> And it made me define _why_ I like TIB_Dataset.Eof the way it is. And
> I (re)learned something about TDataset in the process...
>
>
> Greetings!
> Paul Vinkenoog
>
> --> End-of-mail. Don't try to read this line, it's invalid! <--
>
>
>
>

___________________________________________________________________________

> IB Objects - direct, complete, custom connectivity to Firebird or

InterBase

> without the need for BDE, ODBC or any other layer.
>

___________________________________________________________________________

> http://www.ibobjects.com - your IBO community resource for Tech Info

papers,

> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>