Re: [Lazarus] Wish, remove this GTK2 debug line
On Wed, Oct 12, 2016 at 1:41 AM, Alexey via Lazarus wrote: > Hm, this is work to make an example; why not to comment this msg in GTK2 > widget? You can comment it. You have the sources. However it must be kept in the public sources because it is a valid warning. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Wish, remove this GTK2 debug line
On 11.10.2016 16:59, Mattias Gaertner via Lazarus wrote: Please create bug report with an example to reproduce this. Hm, this is work to make an example; why not to comment this msg in GTK2 widget? -- Regards, Alex -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
> > Which FPC version is this likely to be released in?> 3.0.2 - no3.0.4 - ? 3.2.0 - yes> On a quick review of the code, all seems good. Just one point: >GetDataSize seems to acknowledge CP_UTF8 as the only multibyte >character set. The Firebird character set GB18030 (Chinese >characters) is multi-byte (see wikipedia) and has code page 54936. I >believe PostgreSQL also supports it.I am aware of it. I have not added all other MBCS because I doubt, which are realy used nowadays.My guess is that UTF-8 is far most used / supported as client character set.No problem to add them if there will be real demand from users ...-Laco. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
On Tuesday 11 October 2016 16:19:18 Tony Whyman via Lazarus wrote: > On 11/10/16 15:14, Martin Schreiber via Lazarus wrote: > > case i2 of > > 5,6,8,44,56,57,64: begin > > Agree with 5,6, 44, 56, 57 as two byte character sets. > > 8 doesn't seem to exist (at least in my version). > > 64 is KOI8U. According to Wikipedia "KOI8-U is an 8-bit character > encoding, designed to cover Ukrainian, which uses a Cyrillic alphabet. > It is based on KOI8-R, which covers Russian and Bulgarian, but replaces > eight graphic characters with four Ukrainian letters Ґ, Є, І, and Ї in > both upper case and lower case." > > It should be the same character width as character set 63 (KOI8R) i.e. 1. I don't remember from where I got the numbers. Maybe by reading FB-sources or reading RDB$BYTES_PER_CHARACTER. On my current FB 2.5 installation "64" actually is 1 byte per character, thanks for pointing it out, it allready has been fixed in git master. In MSEgui and the newer ZEOSlib versions the datasize of a string in TDataset record buffer is sizeof(pointer). In MSEgui it is a UnicodeString in ZEOS IIRC a pointer to a special string record. Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
On 11/10/16 15:14, Martin Schreiber via Lazarus wrote: MSEgui uses below code in order to guess the Firebird character size: " FYI, this is the table IBX uses to look up character sets and code pages: CharSetMap: array [0..69] of TCharsetMap = ( (CharsetID: 0; CharSetName: 'NONE'; CharSetWidth: 1; CodePage: CP_NONE), (CharsetID: 1; CharSetName: 'OCTETS'; CharSetWidth: 1; CodePage: CP_NONE), (CharsetID: 2; CharSetName: 'ASCII'; CharSetWidth: 1; CodePage: CP_ASCII), (CharsetID: 3; CharSetName: 'UNICODE_FSS'; CharSetWidth: 3; CodePage: CP_UTF8), (CharsetID: 4; CharSetName: 'UTF8'; CharSetWidth: 4; CodePage: CP_UTF8), (CharsetID: 5; CharSetName: 'SJIS_0208'; CharSetWidth: 2; CodePage: 20932), (CharsetID: 6; CharSetName: 'EUCJ_0208'; CharSetWidth: 2; CodePage: 20932), (CharsetID: 7; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 8; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 9; CharSetName: 'DOS737'; CharSetWidth: 1; CodePage: 737), (CharsetID: 10; CharSetName: 'DOS437'; CharSetWidth: 1; CodePage: 437), (CharsetID: 11; CharSetName: 'DOS850'; CharSetWidth: 1; CodePage: 850), (CharsetID: 12; CharSetName: 'DOS865'; CharSetWidth: 1; CodePage: 865), (CharsetID: 13; CharSetName: 'DOS860'; CharSetWidth: 1; CodePage: 860), (CharsetID: 14; CharSetName: 'DOS863'; CharSetWidth: 1; CodePage: 863), (CharsetID: 15; CharSetName: 'DOS775'; CharSetWidth: 1; CodePage: 775), (CharsetID: 16; CharSetName: 'DOS858'; CharSetWidth: 1; CodePage: 858), (CharsetID: 17; CharSetName: 'DOS862'; CharSetWidth: 1; CodePage: 862), (CharsetID: 18; CharSetName: 'DOS864'; CharSetWidth: 1; CodePage: 864), (CharsetID: 19; CharSetName: 'NEXT'; CharSetWidth: 1; CodePage: CP_NONE), (CharsetID: 20; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 21; CharSetName: 'ISO8859_1'; CharSetWidth: 1; CodePage: 28591), (CharsetID: 22; CharSetName: 'ISO8859_2'; CharSetWidth: 1; CodePage: 28592), (CharsetID: 23; CharSetName: 'ISO8859_3'; CharSetWidth: 1; CodePage: 28593), (CharsetID: 24; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 25; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 26; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 27; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 28; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 29; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 30; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 31; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 32; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 33; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 34; CharSetName: 'ISO8859_4'; CharSetWidth: 1; CodePage: 28594), (CharsetID: 35; CharSetName: 'ISO8859_5'; CharSetWidth: 1; CodePage: 28595), (CharsetID: 36; CharSetName: 'ISO8859_6'; CharSetWidth: 1; CodePage: 28596), (CharsetID: 37; CharSetName: 'ISO8859_7'; CharSetWidth: 1; CodePage: 28597), (CharsetID: 38; CharSetName: 'ISO8859_8'; CharSetWidth: 1; CodePage: 28598), (CharsetID: 39; CharSetName: 'ISO8859_9'; CharSetWidth: 1; CodePage: 28599), (CharsetID: 40; CharSetName: 'ISO8859_13'; CharSetWidth: 1; CodePage: 28603), (CharsetID: 41; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 42; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 43; CharSetName: 'Unknown'; CharSetWidth: 0; CodePage: CP_NONE), (CharsetID: 44; CharSetName: 'KSC_5601'; CharSetWidth: 2; CodePage: 949), (CharsetID: 45; CharSetName: 'DOS852'; CharSetWidth: 1; CodePage: 852), (CharsetID: 46; CharSetName: 'DOS857'; CharSetWidth: 1; CodePage: 857), (CharsetID: 47; CharSetName: 'DOS861'; CharSetWidth: 1; CodePage: 861), (CharsetID: 48; CharSetName: 'DOS866'; CharSetWidth: 1; CodePage: 866), (CharsetID: 49; CharSetName: 'DOS869'; CharSetWidth: 1; CodePage: 869), (CharsetID: 50; CharSetName: 'CYRL'; CharSetWidth: 1; CodePage: 1251), (CharsetID: 51; CharSetName: 'WIN1250'; CharSetWidth: 1; CodePage: 1250), (CharsetID: 52; CharSetName: 'WIN1251'; CharSetWidth: 1; CodePage: 1251), (CharsetID: 53; CharSetName: 'WIN1252'; CharSetWidth: 1; CodePage: 1252), (CharsetID: 54; CharSetName: 'WIN1253'; CharSetWidth: 1; CodePage: 1253), (CharsetID: 55; CharSetName: 'WIN1254'; CharSetWidth: 1; CodePage: 1254), (CharsetID: 56; CharSetName: 'BIG_5'; CharSetWidth: 2; CodePage: 950), (CharsetID: 57; CharSetName: 'GB_2312'; CharSetWidth: 2; CodePage: 936), (CharsetID: 58; CharSetName: 'WIN1255'; CharSetWidth: 1; CodePage: 1255), (CharsetID: 59; CharSetName: 'WIN1256'; CharSetWidth: 1; CodePage: 1256), (CharsetID: 60; CharSetName: 'WIN1257'; CharSetWidth: 1; CodePage: 1257), (CharsetID: 61; CharSetNam
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
On 11/10/16 15:14, Martin Schreiber via Lazarus wrote: case i2 of 5,6,8,44,56,57,64: begin Agree with 5,6, 44, 56, 57 as two byte character sets. 8 doesn't seem to exist (at least in my version). 64 is KOI8U. According to Wikipedia "KOI8-U is an 8-bit character encoding, designed to cover Ukrainian, which uses a Cyrillic alphabet. It is based on KOI8-R, which covers Russian and Bulgarian, but replaces eight graphic characters with four Ukrainian letters Ґ, Є, І, and Ї in both upper case and lower case." It should be the same character width as character set 63 (KOI8R) i.e. 1. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
On Tuesday 11 October 2016 15:48:15 Tony Whyman via Lazarus wrote: > Please look at changes in TRUNK. > > > May be that not all is perfect, but you will see there direction ... > > > > -Laco. > > Which FPC version is this likely to be released in? > > On a quick review of the code, all seems good. Just one point: > GetDataSize seems to acknowledge CP_UTF8 as the only multibyte character > set. The Firebird character set GB18030 (Chinese characters) is > multi-byte (see wikipedia) and has code page 54936. I believe PostgreSQL > also supports it. MSEgui uses below code in order to guess the Firebird character size: " SQL_TEXT,SQL_VARYING: begin size:= metadata.getlength(fapi.status,i1); datatype:= ftstring; i2:= metadata.getcharset(fapi.status,i1); if _type = SQL_TEXT then begin fetchfunc:= @fetchtext; if i2 = cs_binary then begin if size = 16 then begin datatype:= ftguid; fetchfunc:= @fetchguid; size:= 0; end else begin datatype:= ftbytes; end; end; end else begin if i2 = cs_binary then begin datatype:= ftvarbytes; fetchfunc:= @fetchvarbytes; end else begin fetchfunc:= @fetchvarchar; end; end; case i2 of 5,6,8,44,56,57,64: begin i3:= 2; end; 3: begin i3:= 3; end; 4,59: begin i3:= 4; end; else begin i3:= 1; end; end; size:= size div i3; end; " From https://gitlab.com/mseide-msegui/mseide-msegui/blob/master/lib/common/db/msefbconnection.pas Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Wish, remove this GTK2 debug line
On Tue, 11 Oct 2016 04:31:58 +0300 Alexey via Lazarus wrote: > On 11.10.2016 04:29, Alexey via Lazarus wrote: > > remove that Debug line which prints error. > > I misread the subject: I mean that debug line- > > user@user-Notebook:~$ cudatext > WARNING: TGtk2WidgetSet.InvalidateRect refused invalidating during paint > message: TATSynEdit That's not a debug line. It's a warning, that the GTK interface had to break an endless loop. Please create bug report with an example to reproduce this. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
Please look at changes in TRUNK. May be that not all is perfect, but you will see there direction ... -Laco. Which FPC version is this likely to be released in? On a quick review of the code, all seems good. Just one point: GetDataSize seems to acknowledge CP_UTF8 as the only multibyte character set. The Firebird character set GB18030 (Chinese characters) is multi-byte (see wikipedia) and has code page 54936. I believe PostgreSQL also supports it. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
An IBX user came to me with a problem and the problem seems to be a deep seated disconnect between multi-byte character sets, TStringField.Size and TDBEdit.MaxLength. Something needs to give - but I am not sure what should. Firstly documentation: If you go back to Delphi, TField.DataSize is the memory needed to hold the Field's value. The DisplayWidth is the number of characters to be displayed, and Size is, for datatype ftstring, "the maximum number of characters in the string". Right. TStringField.Size is size of characters, not bytes How literally this last definition should be taken, I'm not sure, as it may well have been written assuming a single byte character set. On the other hand, the FPC documentation is consistent with Delphi for DisplayWidth and DataSize, but more opaque for TField.Size where it is the "logical size" - whatever that means, although TStringField is more definitive by saying it is the maximum size (in characters) - their brackets not mine. That seems to be consistent with TDBEdit.Maxlength which should be the maximum number of characters that can appear in the control and, if you look at the code, TDBEdit will source the default value from FDatalink.Size (And also seems to ignore DisplayWidth). TDBEdit.MaxLength must correspond to TStringField.Size The problem comes when you look at the code for TStringField.GetValue, where it starts off as: function TStringField.GetValue(var AValue: string): Boolean; var Buf, TBuf : TStringFieldBuffer; DynBuf, TDynBuf : Array of char; begin if DataSize <= dsMaxStringSize then begin Result:=GetData(@Buf); Buf[Size]:=#0; //limit string to Size If Result then begin ... Look at TRUNK, there is already changed code, which takes DataSize ;-) If nothing else, this is a "bug in waiting". TStringField.GetDataSize always returns "Size+1", so "Buff[Size]:=#0; should work - but only as long as the virtual method "GetDataSize" is not overridden (GetValue is non-virtual) and Size is the byte length of the string! in TRUNK is GetDataSize changed also, it takes into account Fields CharSet and for UTF8 returns 4*Size+1 There is a built-in assumption here that "Size" is the byte length of the string and not the character length. this assumption came from old Delphi days, where it was so for SBCS If you have a multi-byte character set and set size to the number of characters and DataSize to e.g. for UTF8 4*(no of characters)+1, then you will get string corruption as a result of the above. IBX handles multi-byte character sets and does so by defining TIBStringField as a subclass of TStringFIeld and setting size to the byte length and the Default DisplayWidth to the character width. This is compatible with TStringField as it works today. It also seems to be compatible with TDBGrid, which uses Field.DisplayWidth. However, it does result in TDBEdit accepting too many characters. What should be done? It's a problem. Ideally, the TStringField code should be aligned with the documentation. However, that could break existing code and would need to handled carefully. TStringFIeld also needs fixing i.e. to Buf[DataSize-1]:=#0 in order to make this a reality. Size must be character size (used for visual components if they handle characters) DataSize must be byte size (used for record buffers to store character data) Alternatively, the documentation could be amended to reflect the implementation. This means that TDBEdit (and maybe more) have to be updated - but why doesn't TDBEdit respect the DisplayWidth property anyway? Perhaps, it is also about time that TStringField got a characterWidth property to hold the maximum number of bytes for each character. That would at least allow the DataSize to be automatically computed from the character width. There is new TFieldDef.CharSize which says how many bytes is one character If I had to write a bug report today, I would write it to avoid changes to IBX - but then is that the right answer? Please look at changes in TRUNK. May be that not all is perfect, but you will see there direction ... -Laco. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK2 version and backspace key in Edit fields
Okay, applied the patch and the bug appears to be fixed. Sorry for the extra noise. On 11/10/16 08:46 AM, David Copeland via Lazarus wrote: > Cancel that, not sure yet, didn't apply the patch yet. > > On 11/10/16 08:39 AM, David Copeland via Lazarus wrote: >> The bug is still present here. >> >> FPC 3.0, Lazarus r53093. >> OpenSuse 42.1 >> glib2 2.44.1 >> gtk2 2.24.31 >> >> Dave Copeland. >> >> > -- David Copeland JSI Data Systems Limited 613-727-9353 www.jsidata.ca -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TDBEdit, TStringField Size, DataSize, DisplayWidth and MaxLength
An IBX user came to me with a problem and the problem seems to be a deep seated disconnect between multi-byte character sets, TStringField.Size and TDBEdit.MaxLength. Something needs to give - but I am not sure what should. Firstly documentation: If you go back to Delphi, TField.DataSize is the memory needed to hold the Field's value. The DisplayWidth is the number of characters to be displayed, and Size is, for datatype ftstring, "the maximum number of characters in the string". How literally this last definition should be taken, I'm not sure, as it may well have been written assuming a single byte character set. On the other hand, the FPC documentation is consistent with Delphi for DisplayWidth and DataSize, but more opaque for TField.Size where it is the "logical size" - whatever that means, although TStringField is more definitive by saying it is the maximum size (in characters) - their brackets not mine. That seems to be consistent with TDBEdit.Maxlength which should be the maximum number of characters that can appear in the control and, if you look at the code, TDBEdit will source the default value from FDatalink.Size (And also seems to ignore DisplayWidth). The problem comes when you look at the code for TStringField.GetValue, where it starts off as: function TStringField.GetValue(var AValue: string): Boolean; var Buf, TBuf : TStringFieldBuffer; DynBuf, TDynBuf : Array of char; begin if DataSize <= dsMaxStringSize then begin Result:=GetData(@Buf); Buf[Size]:=#0; //limit string to Size If Result then begin ... If nothing else, this is a "bug in waiting". TStringField.GetDataSize always returns "Size+1", so "Buff[Size]:=#0; should work - but only as long as the virtual method "GetDataSize" is not overridden (GetValue is non-virtual) and Size is the byte length of the string! There is a built-in assumption here that "Size" is the byte length of the string and not the character length. If you have a multi-byte character set and set size to the number of characters and DataSize to e.g. for UTF8 4*(no of characters)+1, then you will get string corruption as a result of the above. IBX handles multi-byte character sets and does so by defining TIBStringField as a subclass of TStringFIeld and setting size to the byte length and the Default DisplayWidth to the character width. This is compatible with TStringField as it works today. It also seems to be compatible with TDBGrid, which uses Field.DisplayWidth. However, it does result in TDBEdit accepting too many characters. What should be done? It's a problem. Ideally, the TStringField code should be aligned with the documentation. However, that could break existing code and would need to handled carefully. TStringFIeld also needs fixing i.e. to Buf[DataSize-1]:=#0 in order to make this a reality. Alternatively, the documentation could be amended to reflect the implementation. This means that TDBEdit (and maybe more) have to be updated - but why doesn't TDBEdit respect the DisplayWidth property anyway? Perhaps, it is also about time that TStringField got a characterWidth property to hold the maximum number of bytes for each character. That would at least allow the DataSize to be automatically computed from the character width. If I had to write a bug report today, I would write it to avoid changes to IBX - but then is that the right answer? Tony Whyman MWA -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK2 version and backspace key in Edit fields
Cancel that, not sure yet, didn't apply the patch yet. On 11/10/16 08:39 AM, David Copeland via Lazarus wrote: > The bug is still present here. > > FPC 3.0, Lazarus r53093. > OpenSuse 42.1 > glib2 2.44.1 > gtk2 2.24.31 > > Dave Copeland. > > -- David Copeland JSI Data Systems Limited 613-727-9353 www.jsidata.ca -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK2 version and backspace key in Edit fields
The bug is still present here. FPC 3.0, Lazarus r53093. OpenSuse 42.1 glib2 2.44.1 gtk2 2.24.31 Dave Copeland. > > On 2016-10-10 23:08, Juha Manninen via Lazarus wrote: >> Regarding issue: >> http://bugs.freepascal.org/view.php?id=30596 >> >> GTK2 users please test if there is any version that needs special >> treatment. >> If not, then I will remove the GTK2 version checks. >> See the last 2 notes in the bug report for details please. >> >> Juha > > -- David Copeland JSI Data Systems Limited 613-727-9353 www.jsidata.ca -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK2 version and backspace key in Edit fields
I have no idea about the versioning with the glib2/gtk2 lib, but I can confirm that the patch works here: Free Pascal Compiler version 3.0.0 Compiler date : 2015/11/26 Compiler CPU target: x86_64 Lazarus trunk: r53093 glib2: 2.48.2 gtk2: 2.24.31 Torsten. On 2016-10-10 23:08, Juha Manninen via Lazarus wrote: Regarding issue: http://bugs.freepascal.org/view.php?id=30596 GTK2 users please test if there is any version that needs special treatment. If not, then I will remove the GTK2 version checks. See the last 2 notes in the bug report for details please. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
