On Thu, 30 Oct 2014, Joost van der Sluis wrote:
On 10/30/2014 04:34 PM, Michael Van Canneyt wrote:
On Thu, 30 Oct 2014, Michael Van Canneyt wrote:
On Thu, 30 Oct 2014, Luca Olivetti wrote:
Hello,
TFixedFormatDataSet (ancestor of TSdfDataSet) overrides GetRecNo
(correct) but it does a strange contortion instead of simply returning
FCurRec:
function TFixedFormatDataSet.GetRecNo: Longint;
var
BufPtr: TRecordBuffer;
begin
Result := -1;
if GetActiveRecBuf(BufPtr) then
Result := PRecInfo(BufPtr + FRecInfoOfs)^.RecordNumber;
The records in the buffer may be in a different order than they are
displayed in the grid.
Forget this. I was too quick to respond.
I have done some digging, but cannot find a reason for the current
behaviour.
Easy: Some systems use the recno as some sort of 'bookmark'. And some people
insist that this is the correct behaviour for a dataset. (Note that for
TBufDataset a call to recno is really slow, as it has to iterate over all
records to get the correct recno.)
AFAIK RecNo has no meaning when you work with multiple indexes and filters.
So some datasets have recno's that uniquely identify a record. I've tried to
unify that once, but that was not easily done. So I decided to leave this
decision to the author of each dataset. Hence the GetRecNo.
I understand why the GetRecNo is there, just not why it is implemented as it is
in TSDFDataset.
(which is what I was investigating)
But that TDBGrid uses the recno is troublesome... But I don't see a better
solution.
Delphi DBGrid does not use recno, so it must be possible...
AFAIK TDatalink has special provisions to provide a window buffer.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
