Re: [fpc-devel] About TDataSet master/detail design in fpc
On 5/6/05, Luiz Américo <[EMAIL PROTECTED]> wrote: > Michael Van Canneyt wrote: > > > > > > On Fri, 6 May 2005, Luiz Américo wrote: > > > >> I noticed that in the current cvs of fpc it's implemented the > >> master/detail relation between TDataset(s). > >> I saw that TDetailDataLink and TMasterDataLink was introduced but I > >> couldn't figure how is supposed to work. I also noticed the abscense > >> of NestedDatasets and DataSetField properties. > > > > > > They are not yet implemented. > > So none of the current TDataset descendants works with Master/Detail > schema ? > If some works, can anybody send me a example? MasterDetail works, and you don't need NestedDatasets or DataSetFields for that. 1. Put a Master dataset and a Datasource on a form, connect them and fill the properties. 2. Put a Detail dataset and a Datasource and connect them. 3. In Detail dataset set 3 properties: Index, Master dataset, and Master fields. That's all Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] error compiling from current svn
there is an error compilling in winunits: D:/lazarus/fpcsrc/compiler/ppc386.exe -XX -CX -Xs -OG2p3 -n -FuD:/lazarus/fpcsrc /rtl/units/i386-win32 -FE. -FUunits/i386-win32 -di386 -dRELEASE jwawownt16.pas jwawownt16.pas(55,2) Error: Wrong switch toggle, use ON/OFF or +/- jediapilib.inc(38,2) Warning: Unsupported switch "$A" JwaWinNT.pas(8939,1) Fatal: There were 1 errors compiling module, stopping Error: Compilation aborted make[5]: *** [jwawownt16.ppu] Error 1 make[5]: Leaving directory `D:/lazarus/fpcsrc/packages/extra/winunits' make[4]: *** [fpc_smart] Error 2 make[4]: Leaving directory `D:/lazarus/fpcsrc/packages/extra/winunits' make[3]: *** [winunits_smart] Error 2 make[3]: Leaving directory `D:/lazarus/fpcsrc/packages/extra' make[2]: *** [extra_smart] Error 2 make[2]: Leaving directory `D:/lazarus/fpcsrc/packages' make[1]: *** [packages_extra_smart] Error 2 make[1]: Leaving directory `D:/lazarus/fpcsrc' make: *** [build-stamp.i386-win32] Error 2 seems that SYMBOL_PLATFORM used here is not defined. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc-svn177-units-Mysql broken
there is an inconsistency:
TDateTimeRec = record
case TFieldType of
ftDate: (Date: Longint);
ftTime: (Time: Longint);
ftDateTime: (DateTime: TDateTimeAlias);
end;
TTimeStamp = record
Time: integer; { Number of milliseconds since midnight }
Date: integer; { One plus number of days since 1/1/0001 }
end ;
TTimeStamp,Date is integer, and TDateTimeRec.ftDate is longint.
on AMD 64 integer<>longint?
Alex
On 6/3/05, Jan Ruzicka <[EMAIL PROTECTED]> wrote:
> Hi
>
> the latest version (177) of fpc in svn does not compile on Mac OS X
> 10.3.9.
>
> The make all ends with following:
>
> /Users/j/fpc/fpc-svn/compiler/ppcppc -Xs -O1 -n -S2
> -Fu/Users/j/fpc/fpc-svn/rtl/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/ibase/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/postgres/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/mysql/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/sqlite/units/powerpc-darwin -FE.
> -FU/Users/j/fpc/fpc-svn/fcl/units/powerpc-darwin -dpowerpc -dRELEASE
> db.pp
> dataset.inc(468,54) Error: Incompatible type for arg no. 1: Got
> "TDateTimeAlias", expected "Int64"
> db.pp(2025) Fatal: There were 1 errors compiling module, stopping
> db.pp(2025) Error: Compilation aborted
> make[3]: *** [db.ppu] Error 1
> make[2]: *** [db_all] Error 2
> make[1]: *** [fcl_all] Error 2
> make: *** [build-stamp.powerpc-darwin] Error 2
>
> >>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc-svn177-units-Mysql broken
IMHO we don't need date on 64 bit:
TDateTimeRec = record
case TFieldType of
ftDate: (Date: integer);
ftTime: (Time: integer);
ftDateTime: (DateTime: TDateTimeAlias);
end;
On 6/3/05, Peter Vreman <[EMAIL PROTECTED]> wrote:
> At 08:09 3-6-2005, you wrote:
> >there is an inconsistency:
> >
> > TDateTimeRec = record
> > case TFieldType of
> > ftDate: (Date: Longint);
> > ftTime: (Time: Longint);
> > ftDateTime: (DateTime: TDateTimeAlias);
> > end;
> >
> >TTimeStamp = record
> > Time: integer; { Number of milliseconds since midnight }
> > Date: integer; { One plus number of days since 1/1/0001 }
> >end ;
> >
> >TTimeStamp,Date is integer, and TDateTimeRec.ftDate is longint.
> >
> >on AMD 64 integer<>longint?
>
> integer is 32 bit.
>
>
> Peter
>
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DB Bug in 2.0.1?
On 7/21/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Wed, 20 Jul 2005, Tony Maro wrote: > > > Jonas Maebe wrote: > > > > > > > > On 21 jul 2005, at 00:40, Tony Maro wrote: > > > > > > > Can someone confirm the date issue for me? > > > > > > > > > I can't confirm it, but I do want to mention that I fixed all > > > datetime-related routines for *nix platforms in sysutils a while ago. > > > They operated based on the supposition that the dates they get are in > > > Windows format, as opposed to the number of seconds since x/x/1970. > > > > I have a concern on that - and please keep in mind I've not even looked at > > the > > code, so I don't know if it's an issue or not. > > > > My main purpose in using FPC is to write cross-platform applications. From > > what I gather, I'll now need to understand that TDateTime doesn't actually > > store things the same way on different OS's? I know, FPC's goal is not > > specifically Delphi compatibility, but... > > > > Here's a quote I found online: > > "In Delphi for Win32 (and Kylix), TDateTime is defined as a Double (64-bit > > floating-point number). Date and time information is stored as the count of > > days since midnight on 30-Dec-1899." > > > > Here you can see that even Kylix uses the same methodology in storing > > TDateTime values. > > The TDateTime value itself is not the issue. It is the same on all platforms, > and compatible to Delpi. > > > > > I can see both perspectives, but if the idea is to make it easier to develop > > cross-platform software, I'd expect TDateTime to be stored the same way > > across > > platforms regardless of how the OS counts. A lot of software written for > > Delphi is going to be awfully hard to convert for Linux, Mac, etc if > > TDateTime > > is stored differently everywhere. > > It is not. > > If I remember correctly, there have been some fixes on the internal Date/Time > field buffer format of TDataset, and I suppose your problem is a result of > that > change. > > Michael. > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > I think you need at least dbf_common.inc from fpc package. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DB Bug in 2.0.1?
On 7/21/05, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> On Thu, 21 Jul 2005 06:51:12 +0200 (CEST)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> > Because of the bug report I did some research on this as well.
> > Up to and including D4, a TDateTimeRec was used internally.
> > As of Delphi 5, TDateTime was used.
> >
> > Since the first FPC TDataset implementation was based on a D3 spec,
> > this explains the confusion.
>
> Yes, but FPC already used TDateTime internally, according to TDbf :-)
>
> dbf_common.inc:
>
> {$ifdef DELPHI_5}
>
> ...
> {$define SUPPORT_NEW_FIELDDATA}
> ...
>
> SUPPORT_NEW_FIELDDATA means use TDateTime as internal format. Under {$ifdef
> FPC} I also have defined SUPPORT_NEW_FIELDDATA.
>
> (I know: the SUPPORT_ should be named HAS_ or so...)
>
> Regards from the not entirely ignorant tdbf maintainer as proven by this mail
> ;-)
>
> Micha
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
It is not about SUPPORT_NEW_FIELDDATA, but
SUPPORT_BACKWARD_FIELDDATA.
In fcp package, in dbf_common.inc it is defined
SUPPORT_BACKWARD_FIELDDATA but in
last package on sourceforge not.
Alex
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DB Bug in 2.0.1?
On 7/21/05, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> On Thu, 21 Jul 2005 13:25:05 +0300
> Alexandrov Alexandru <[EMAIL PROTECTED]> wrote:
>
> > On 7/21/05, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> > > On Thu, 21 Jul 2005 06:51:12 +0200 (CEST)
> > > Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> > >
> > > > Because of the bug report I did some research on this as well.
> > > > Up to and including D4, a TDateTimeRec was used internally.
> > > > As of Delphi 5, TDateTime was used.
> > > >
> > > > Since the first FPC TDataset implementation was based on a D3 spec,
> > > > this explains the confusion.
> > >
> > > Yes, but FPC already used TDateTime internally, according to TDbf :-)
> >
> > It is not about SUPPORT_NEW_FIELDDATA, but
> > SUPPORT_BACKWARD_FIELDDATA.
> >
> > In fcp package, in dbf_common.inc it is defined
> > SUPPORT_BACKWARD_FIELDDATA but in
> > last package on sourceforge not.
>
> I see, the backward compatible translation thingy. Why didn't you report this
> to me ?
>
> 'Official' TDbf has never had the SUPPORT_BACKWARD_FIELDDATA defined for FPC.
>
> Micha
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
I have sent an patch (2 month ago) to improve the compatibility with
some older tdataset components.
I have included corrections to all related components: interbase,
mysql3 and 4, sqldb, tdbf.
I don't know who is maintainer for each component.
this was about tdbf:
--- dbase/dbf_common.inc(revision 171)
+++ dbase/dbf_common.inc(working copy)
@@ -170,6 +170,7 @@
{$define SUPPORT_INT64}
{$define SUPPORT_DEFAULT_PARAMS}
{$define SUPPORT_NEW_TRANSLATE}
+ {$define SUPPORT_BACKWARD_FIELDDATA}
{$define SUPPORT_NEW_FIELDDATA}
{$define SUPPORT_FIELDDEF_TPERSISTENT}
{$define SUPPORT_FIELDTYPES_V4}
Alex
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch to remove useless bookmark store in TDataset.DoInsertAppend
On 7/24/05, Luiz Américo <[EMAIL PROTECTED]> wrote:
> As already commented in the code, the bookmarking done inside
> TDataset.DoInsertAppend is useless, not to say buggy.
> It makes 2 records to have the same bookmark data but this is not
> noticed because the bookmarkdata is set to the correct value after
> Post->Resync.
>
> In TDBF, if the bookmark is get just after a insert call this bookmark
> will point to the previous record (see the attached example).
>
> The patch remove this code and also refactory a if statement.
>
> Unfortunately, after applying the patch if a bookmark is get after
> insert this bookmark points to the first record. This occurs because
> TDBF inits a buffer with BookMarkData=0 and BookMarkFlag=bfCurrent
> instead of bfInserted (this makes bookmarkavailable returns true)
>
> As far as i can understand it seems that is not allowed to get a
> bookmark in a not posted record, is it?
You can bookmark at any time. But as the inserted record is not posted
yet, the bookmark will point to the current record in dataset.
Multiple users can insert records at same time.
>
> BTW is necessary/correct the SetBookMarkFlag call (inside DoInsert) in
> this procedure ?
>
> Luiz
>
>
> program testbookdbf;
> {$Mode ObjFpc}
> {$H+}
>
> uses
> sysutils,classes,db,dbf;
> var
> Counter:Integer;
> FDataset:TDbf;
> Book0,Book1:TBookMarkStr;
> begin //Main
> FDataSet:=TDbf.Create(nil);
> with FDataSet do
> begin
>FilePathFull:=ExtractFilePath(ParamStr(0));
>Tablename:='dbf_book.db';
>if FileExists(FilePathFull+TableName) then
> DeleteFile(FilePathFull+TableName);
>if not FileExists(FilePathFull+TableName) then
>begin
> FieldDefs.Clear;
> FieldDefs.Add('Int',ftInteger);
> FieldDefs.Add('Str',ftString);
> CreateTable;
>end;
>Open;
>//add 2 records
>
>Insert;
>FieldByName('Int').AsInteger:=-1;
>FieldByName('Str').AsString:='minus';
>Post;
>
>Insert;
>FieldByName('Int').AsInteger:=0;
>FieldByName('Str').AsString:='zero';
>Post;
>Book0:=Bookmark;
>
>Insert;
>Book1:=Bookmark;
>FieldByName('Int').AsInteger:=1;
>FieldByName('Str').AsString:='one';
>Post;
>Book1:=Bookmark; //Comment this to get the error
>
>//Now go to bookmarks
>Last;
>writeln('Record before going to books: ',FieldByName('Int').AsInteger);
>BookMark:=Book1;
>writeln('Bookmark set to book1');
>writeln('Current Record: ',FieldByName('Int').AsInteger);
>BookMark:=Book0;
>writeln('Bookmark set to book0');
>writeln('Current Record: ',FieldByName('Int').AsInteger);
>Free;
> end;
> end.
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>
>
>
This example is bad. See above.
Most datasets don't allow inserting records. Including TDbf.
If a dataset allow to insert records, and if the bookmark is the same
as record number, then the new record must have the same bookmark as
the old record.
Next records bookmarks must be changed.
If the record is appended, after DoInsert, follow
SetBookmarkFlag(ActiveBuffer,bfEOF);
It is ok i think.
Alex
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fixed date/time formats for sqldb and tdbf?
Hi In revision 803 log: Fixed date/time formats for sqldb and tdbf I don't understand what is fixed. Beside that, the compatibility with databases that use TDateTimeRec is broken. They used this format before D4 and they still use now for compatibility. D7 can handle this format. FPC no more, since this revision. IMO there is nothing fixed there, but broken. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fixed date/time formats for sqldb and tdbf?
On 8/11/05, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > > In revision 803 log: Fixed date/time formats for sqldb and tdbf > > I don't understand what is fixed. > > Beside that, the compatibility with databases that use TDateTimeRec is > > broken. > > They used this format before D4 and they still use now for > > compatibility. D7 can handle this format. FPC no more, since this > > revision. > > IMO there is nothing fixed there, but broken. > > Well, as it was, id didn't work for any database which uses TDateTime, > which are all fpc-databases and all Delphi databases written for D4+. > > Personally I don't know any TDatabase descendents that can't work with > TDateTime. Can you give me one? Then I can look for a solution. > > Regards, > Joost. > I was sent the patch that fixed this compatibility (and i explained that). I agree that we can remove the old code when are no more compatible with the rest of code, but this piece of code do not harm anyone. I can't send the component to you because it is not free, but after registration you may find it here: http://devzone.advantagedatabase.com/as/advantage_solutions.dll After one hour spent for conversion, this components works great. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some Dataset and Variants patches
On 9/16/05, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > Any reason to re-implement the tempbuffer? Or were you just using an > older version? > > regards, > Joost. > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > It seems that there are many delphi compatible components left that use tempbuffer. I have myself reintroduced this function instantly, becouse it is used in filtering/searching operations by my dataset component. Since this function exists in delphi and it is used by some components, i see no reason not to have it in fpc. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some Dataset and Variants patches
On 9/19/05, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > > It seems that there are many delphi compatible components left that > > use tempbuffer. I have myself reintroduced this function instantly, > > becouse it is used in filtering/searching operations by my dataset > > component. > > Since this function exists in delphi and it is used by some > > components, i see no reason not to have it in fpc. > > Ok, forget my last message then, i'll re-implement it. > > Do you also know what it should do? > > Regards, > Joost > > Function TDataset.TempBuffer: PChar; begin Result := FBuffers[FRecordCount]; end; The result of this function is used in filtering/searching operations. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc_pchar_length error
The following program will rise an error:
Adress: $00401493
Procedure: fpc_pchar_length
program project1;
{$mode objfpc}{$H+}
uses
Classes;
var Buffer: PChar;
begin
Buffer := Nil;
WriteLn(Length( Buffer ));
end.
is this a bug?
Alex
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_pchar_length error
On 12/11/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 10 Dec 2005, Alexandrov Alexandru wrote:
>
> > The following program will rise an error:
> > Adress: $00401493
> > Procedure: fpc_pchar_length
> >
> >
> > program project1;
> >
> > {$mode objfpc}{$H+}
> >
> > uses
> > Classes;
> >
> > var Buffer: PChar;
> > begin
> > Buffer := Nil;
> > WriteLn(Length( Buffer ));
> > end.
> >
> > is this a bug?
>
> It depends on the specs of "length" :-)
>
> Michael.
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
What do you mean with specs?
btw i forgot to mention, i tested on winxp.
In Delphi the result is 0, and no error.
Alex
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_pchar_length error
On 12/12/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Mon, 12 Dec 2005, Jonas Maebe wrote: > > > > > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: > > > >>> It depends on the specs of "length" :-) > >> > >> What do you mean with specs? > > > > How it is defined to behave in the documentation (i.e., whether the > > documentation says "if you call length with as argument a nil pointer, the > > result is defined to be 0", or "the behaviour of length with as argument a > > nil pointer is undefined", or simply doesn't mention it at all). > > Exactly. > > >> btw i forgot to mention, i tested on winxp. > >> In Delphi the result is 0, and no error. > > > > Delphi obviously is a lot more tolerant to bad programming than we are... A > > pchar which is nil is not an empty string, but an invalid pointer. It's like > > assuming that a nil pointer to a longint is the same as a pointer to the > > value 0 or so. > > I agree with this position. > A Nil pointer is usually a sign of a bad or uninitialized value. ..but we speak here about the length of the string. IMO the length of null string is the same as the length of an unitialised string. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_pchar_length error
On 12/12/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Mon, 12 Dec 2005, Jonas Maebe wrote: > > > > > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: > > > >>> It depends on the specs of "length" :-) > >> > >> What do you mean with specs? > > > > How it is defined to behave in the documentation (i.e., whether the > > documentation says "if you call length with as argument a nil pointer, the > > result is defined to be 0", or "the behaviour of length with as argument a > > nil pointer is undefined", or simply doesn't mention it at all). > > Exactly. > > >> btw i forgot to mention, i tested on winxp. > >> In Delphi the result is 0, and no error. > > > > Delphi obviously is a lot more tolerant to bad programming than we are... A > > pchar which is nil is not an empty string, but an invalid pointer. It's like > > assuming that a nil pointer to a longint is the same as a pointer to the > > value 0 or so. > > I agree with this position. > A Nil pointer is usually a sign of a bad or uninitialized value. ..but we speak here about the length of the string. IMO length of null string = length of unitialised string. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocateNext
On 4/7/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm busy implementing TBufDataset.Locate and friends. I had the idea to > overload Locate like this: > > function Locate(const keyfields: string; const keyvalues: Variant; > options: TLocateOptions; LocateNext : boolean ) : boolean; > > So that it's possible to doe a 'locatenext' > > But I saw that sqlite simply has a 'locatenext' function. But it is also > possible to add a TLocateOption... There is no need to pass again keyfields, keyvalues and options parameters to locate next match. What to do if they are not the same as for first locate? IMO sqlite aproach is better. > > I'm thinking about implementing this (abstract) at the TDataset level. > What option should I choose and what do you guys think the idea? > I think a LocateNext function would be fine. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocateNext
On 4/10/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > > > I'm busy implementing TBufDataset.Locate and friends. I had the idea to > > > overload Locate like this: > > > > > > function Locate(const keyfields: string; const keyvalues: Variant; > > > options: TLocateOptions; LocateNext : boolean ) : boolean; > > > > > > So that it's possible to doe a 'locatenext' > > > > > > But I saw that sqlite simply has a 'locatenext' function. But it is also > > > possible to add a TLocateOption... > > > > There is no need to pass again keyfields, keyvalues and options > > parameters to locate next match. What to do if they are not the same > > as for first locate? > > I planned to give locatenext exactly the same parameters as locate > itself. So you have to pass the same parameters again, but it adds some > flexibility. For example if you're on a 'random' record, and want to > locate the next one. Then you won't need to do a 'locate' first, but can > do a locatenext immediately. Then i suggest you to name that function LocateRest. Both functions are useful. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch to tdataset
added GetIndexDefs and InitFieldDefsFromFields,
implemented Filed.GetIsIndexField.
Alex
Index: dataset.inc
===
--- dataset.inc (revision 3232)
+++ dataset.inc (working copy)
@@ -246,91 +246,91 @@
begin
If assigned(FAfterCancel) then
- FAfterCancel(Self);
+ FAfterCancel(Self);
end;
Procedure TDataset.DoAfterClose;
begin
If assigned(FAfterClose) then
- FAfterClose(Self);
+ FAfterClose(Self);
end;
Procedure TDataset.DoAfterDelete;
begin
If assigned(FAfterDelete) then
- FAfterDelete(Self);
+ FAfterDelete(Self);
end;
Procedure TDataset.DoAfterEdit;
begin
If assigned(FAfterEdit) then
- FAfterEdit(Self);
+ FAfterEdit(Self);
end;
Procedure TDataset.DoAfterInsert;
begin
If assigned(FAfterInsert) then
- FAfterInsert(Self);
+ FAfterInsert(Self);
end;
Procedure TDataset.DoAfterOpen;
begin
If assigned(FAfterOpen) then
- FAfterOpen(Self);
+ FAfterOpen(Self);
end;
Procedure TDataset.DoAfterPost;
begin
If assigned(FAfterPost) then
- FAfterPost(Self);
+ FAfterPost(Self);
end;
Procedure TDataset.DoAfterScroll;
begin
If assigned(FAfterScroll) then
- FAfterScroll(Self);
+ FAfterScroll(Self);
end;
Procedure TDataset.DoAfterRefresh;
begin
If assigned(FAfterRefresh) then
- FAfterRefresh(Self);
+ FAfterRefresh(Self);
end;
Procedure TDataset.DoBeforeCancel;
begin
If assigned(FBeforeCancel) then
- FBeforeCancel(Self);
+ FBeforeCancel(Self);
end;
Procedure TDataset.DoBeforeClose;
begin
If assigned(FBeforeClose) then
- FBeforeClose(Self);
+ FBeforeClose(Self);
end;
Procedure TDataset.DoBeforeDelete;
begin
If assigned(FBeforeDelete) then
- FBeforeDelete(Self);
+ FBeforeDelete(Self);
end;
Procedure TDataset.DoBeforeEdit;
begin
If assigned(FBeforeEdit) then
- FBeforeEdit(Self);
+ FBeforeEdit(Self);
end;
Procedure TDataset.DoBeforeInsert;
@@ -344,28 +344,28 @@
begin
If assigned(FBeforeOpen) then
- FBeforeOpen(Self);
+ FBeforeOpen(Self);
end;
Procedure TDataset.DoBeforePost;
begin
If assigned(FBeforePost) then
- FBeforePost(Self);
+ FBeforePost(Self);
end;
Procedure TDataset.DoBeforeScroll;
begin
If assigned(FBeforeScroll) then
- FBeforeScroll(Self);
+ FBeforeScroll(Self);
end;
Procedure TDataset.DoBeforeRefresh;
begin
If assigned(FBeforeRefresh) then
- FBeforeRefresh(Self);
+ FBeforeRefresh(Self);
end;
Procedure TDataset.DoInternalOpen;
@@ -719,6 +719,21 @@
Result := -1;
end;
+function TDataSet.GetStateFieldValue(State: TDataSetState; Field: TField):
Variant;
+
+var OldState: TDataSetState;
+begin
+ Result := NULL;
+ if Not (Field.FieldKind in [fkData, fkInternalCalc]) then Exit;
+ OldState := FState;
+ FState := State;
+ try
+Result := Field.AsVariant;
+ finally
+ FState := OldState;
+ end;
+end;
+
Function TDataset.GetRecordCount: Longint;
begin
@@ -737,6 +752,48 @@
end;
end;
+procedure TDataSet.InitFieldDefsFromFields;
+
+ procedure CreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
+ var
+I: Integer;
+F: TField;
+FieldDef: TFieldDef;
+ begin
+for I := 0 to Fields.Count - 1 do
+begin
+ F := Fields[I];
+ with F do
+ if FieldKind = fkData then
+ begin
+FieldDef := FieldDefs.AddFieldDef;
+FieldDef.Name := FieldName;
+FieldDef.DataType := DataType;
+FieldDef.Size := Size;
+if Required then
+ FieldDef.Attributes := [faRequired];
+if ReadOnly then
+ FieldDef.Attributes := FieldDef.Attributes + [faReadonly];
+if (DataType = ftBCD) and (F is TBCDField) then
+ FieldDef.Precision := TBCDField(F).Precision;
+ end;
+end;
+ end;
+
+begin
+ { Create FieldDefs from persistent fields if needed }
+ if FieldDefs.Count = 0 then
+ begin
+FieldDefs.BeginUpdate;
+try
+ CreateFieldDefs(FFieldList, FieldDefs);
+finally
+ FieldDefs.EndUpdate;
+end;
+ end;
+end;
+
+
Procedure TDataset.InitRecord(Buffer: PChar);
begin
@@ -1081,6 +1138,22 @@
end;
end;
+procedure TDataSet.SetStateFieldValue(State: TDataSetState; Field: TField;
+ const Value: Variant);
+
+var
+ OldState: TDataSetState;
+begin
+ if Field.FieldKind <> fkData then Exit;
+ OldState := FState;
+ FState := State;
+ try
+Field.AsVariant := Value;
+ finally
+FState := OldState;
+ end;
+end;
+
Function TDataset.Tempbuffer: PChar;
begin
@@ -1975,6 +2048,37 @@
Result := FieldByName(FieldName).Value
end;
+function TDataSet.GetIndexDefs ( IndexDefs: TIndexDefs;
+ IndexTypes: TIndexOptions ) : TIndexDefs;
+
+var i: Integer;
+begin
+ Result := nil;
+ try
+IndexDefs.Update;
+if IndexDefs.Count = 0 then Exit;
+Result := TIndexDefs.Create(TDataset(nil));
+Result.Assign(IndexDefs);
+for i := Result.Count - 1 downto 0 do
+ if (IndexTypes <> []) and ((Result[i].Options * IndexTypes) = []) then
+Res
Re: [fpc-devel] patch to tdataset
On 4/17/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote: > On Sun, 2006-04-16 at 20:46 +0300, Alexandrov Alexandru wrote: > > added GetIndexDefs and InitFieldDefsFromFields, > > implemented Filed.GetIsIndexField. > > Hmm.. Delphi (7) doesn't have the GetIndexDefs and > InitFieldDefsFromField functions? > And I don't see the use of the first function. From the second I can > imagine that it's usefull, but since it's not in Delphi, it should be > placed into a derrivate of TDataset? Or can you explain why it is > generally usefull? But they are in Delphi 7.. In fact this is the main reason i added those functions. > And your TField.GetIsIndexField simply callse TDataset.GetIsIndexField, > which isn't implemented also... In TDataset, GetIsIndexField function is virtual. TDataset is a prototype. Some functions are declared only to be implemented or overrided in tdataset descendants. > And the patch also contains a GetStateFieldValue, which isn't there in > Delphi but it's usefull. Only you set FState directly, I should use > SetTempState, so that the controls are disabled. Or else all datasource- > controls will display the 'old' values from the fields, if I want to get > only one old-value... FState is a simple variable. GetStateFieldValue function saves fstate, retrive the field value and restore fstate back in a single try..finally statement. If this is not safe enough, we can add code to disable and enable controls. > And could you clean up your patch next time. So that all the lines which > only removes ome spaces are gone? Sorry, I use TortoiseSvn and i don't know much about diff format. Alex ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
