You are not logged in.
Leander007 wrote:fDoc.FCharSet=238
So by design, the test will always fail!
These standard fonts will only work with WinAnsiCharset.
Not a problem, just ignore embed=true loop.
See http://synopse.info/fossil/info/0425cea128
Minor lapsus:
In 0425cea128 you added the code in "embed=false" test.
You meant something like this:
for embed := false to true do begin
if embed and (CharSet<>ANSI_CHARSET) then
continue; // StandardFontsReplace will work only with ANSI code pageLeander007 wrote:When compiling the new code I saw that you forgot to rename TPropInfo.Name to TPropInfo.ShortName in SQlite3i18n unit at lines 2850, 2890 to be compilable.
The unit compiles fine by me.
And there is no TPropInfo.Name in lines 2850 and 2890.I suspect you don't have a valid source code content.
Please refresh ALL files.
I was using mnemonic TPropInfo as type and Name as property, that could be more readable (in contrary to @P^.Name), for which type this has changed.
Whole 2850 line is:
AddOnceDynArray(WinAnsiString(TSQLRecord.CaptionName(@P^.Name)));
But type TPropInfo in SQLite3Commons has no Name property, it has ShortName instead and I checked (through the html file viewer) again your latest fossil sources 0425cea128 and the issue still exists.
At this "entry" line of TPdfCanvas.SetFont function condition is not met to reach SetEmbeddedFont procedure:
if (fDoc.FCharSet=ANSI_CHARSET) and fDoc.StandardFontsReplace then begin...
fDoc.FCharSet=238
ANSI_CHARSET=0
fDoc.StandardFontsReplace=False
When compiling the new code I saw that you forgot to rename TPropInfo.Name to TPropInfo.ShortName in SQlite3i18n unit at lines 2850, 2890 to be compilable.
I was in doubts about this, if I got it right, because you said that it works in your case (code page, compiler).
I still don't fill this very natural
, when reading the code e.g. Set(Something) and Expect(Something_Different).
I hope that you understand my confusion
.
I tried with new corrections (d5ddda8451), but PDF tests still fails, because the problem exists in prior lines:
Canvas.SetFont('arial',10,[]); //on second run (embed=true) this should set to Helvetica if I understand correctly
Check(Canvas.Page.Font.Name=Name[embed]); //here we test for Helvetica on second run, but it's always Arial !SLO code page is 1250 and the problems related to code page are gone now with your corrections.
Because the problems (at least mainly) are not Delphi 2009 compiler related, I moved this issues to the new topic "Synopse SQlite3 Unit Tests".
TestSQL3 tests
sources=2011-06-07 [fa3685333d], compiler=Delphi 2009, CodePage=1250
1.6. Synopse PDF:
! - TPdfDocument: 2 / 4 FAILED
! - TPdfDocumentGDI: 1 / 3 FAILED
Total failed: 3 / 7 - Synopse PDF FAILED
2.2. File based:
! - Direct access: 2 / 10,132 FAILED
! - TSQLRestClientDB: 2,002 / 589,109 FAILED
Total failed: 2,004 / 618,271 - File based FAILED
2.3. File based WAL:
! - Direct access: 2 / 10,132 FAILED
! - TSQLRestClientDB: 2,002 / 589,109 FAILED
Total failed: 2,004 / 618,271 - File based WAL FAILED
2.4. Memory based:
! - Direct access: 1 / 10,131 FAILED
! - TSQLRestClientDB: 2,002 / 615,382 FAILED
Total failed: 2,003 / 644,543 - Memory based FAILED
Synopse framework used: 1.13
SQlite3 engine used: 3.7.6.3
Generated with: Delphi 2009 compiler
-----
If we look one failing test per time:
It seems that in PDF test the check about setting different fonts should always fail,
because we never set Helvetica font (always forcing 'arial'?) and it looks like the code:
Canvas.SetFont('arial',10,[]); should be changed to:
Canvas.SetFont(Name[embed],10,[]);Nevertheless it fails eather way, because font is never realy set to Helvetica in function TPdfCanvas.SetFont.
Unit SynSelfTest:
625:
procedure TTestSynopsePDF._TPdfDocument
Name: array[boolean] of PDFString =
('Arial','Helvetica');
...
Canvas.SetFont('arial',10,[]);
Check(Canvas.Page.Font.Name=Name[embed]);
...
Check(Hash32(MS.Memory,MS.Position)=Hash[embed]); //$1780F68C=$A1201D84TestSQL3 compiled with Delphi 2009
I run the tests with debugger using asserts that I could see where it stops.
I did it all to the "file based" tests, because a lot of failures exists for same root problem (Hash32...).
New build was done for each check (after commenting out failing line), because using only compile resulted in very strange behaviour.
Here are results for these tests (in comments are breakable results) from code snapshot 2011-05-26 09:59 c83b1d9aa5:
Unit SynSelfTest:
409:
procedure TTestCryptographicRoutines.Base64;
...
Value64: RawByteString = 'SGVsbG8gL2Mn6XRhaXQg5+Ar';
...
Check(Base64Encode(Value)=Value64);//'SGVsbG8gL2Mn6XRhaXQg53Ir'
Check(BinToBase64(Value)=Value64);//'SGVsbG8gL2Mn6XRhaXQg53Ir'692:
It seems that this check should always fail, because we never set Helvetica font and should be changed to Canvas.SetFont(Name[embed],10,[]);
Nevertheless it fails eather way.
procedure TTestSynopsePDF._TPdfDocument
Name: array[boolean] of PDFString =
('Arial','Helvetica');
...
Canvas.SetFont('arial',10,[]);
Check(Canvas.Page.Font.Name=Name[embed]);620:
Check(Hash32(MS.Memory,MS.Position)=Hash[embed]); //$1780F68C=$A1201D84774:
H := Hash32(MS.Memory,MS.Position); //H = $93E059A5
Check( (H=$93D859A5) or (H=$9FB359A7) );Unit SQLite3Commons:
16559:
T.fAnsi := 'abcde'#233'ef'#224#233; //'abcdeéefŕé' or $61 $62 $63 $64 $65 $E9 $65 $66 $E0 $E9
T.fTest := WinAnsiToUTF8('abcde'#233'ef'#224#233);//'abcdeéefré' or $61 $62 $63 $64 $65 $C3 $A9 $65 $66 $72 $C3 $A9
T.fUnicode := Utf8DecodeToRawUnicode(T.fTest);//'a'#0'b'#0'c'#0'd'#0'e'#0#$E9#0'e'#0'f'#0'r'#0#$E9#0#0 or $61 $00 $62 $00 $63 $00 $64 $00 $65 $00 $E9 $00 $65 $00 $66 $00 $72 $00 $E9 $00 $00
//RawUnicodeToWinAnsi(T.fUnicode) -> 'abcdeéefré' or $61 $62 $63 $64 $65 $E9 $65 $66 $72 $E9
Check(RawUnicodeToWinAnsi(T.fUnicode)=T.fAnsi);16569:
Check(Hash32(s)=$C18C26D);//$D3EFC46D16572:
Check(Hash32(s)=$6DE61E87);//$D18E138916590:
Check(Hash32(s)=$DDAF2211);//$9543E289Unit SQLite3:
5623:
Check(Hash32(JS)=$221D7DBD,'Expected ExecuteJSON result not retrieved'); //$FE4008155633:
Check(Hash32(Demo.ExecuteJSON(Req))=$221D7DBD,'ExecuteJSON crypted'); //$FE4008156376:
Check(Hash32(S)=$6060CC67); //$6C2710BF6380:
Check(Hash32(S)=$A1DF1271); //$670609C8Delphi 2009 was indeed buggy... buggy... barely usable.
The current code compiles fine with Delphi 2010, in all cases.
I said that compiles in Delphi 2009 too, but execution is not ok. Maybe you (I'm missing some low level knowledge and understanding of your implementation) can find what could went wrong and you can find some workaround (even with low level tricks
). I think too, that new implementation can cost to much refactoring and is not worth it if this is only Delphi 2009 issue.
Did you install all Delphi 2009 updates?
Yes.
About TestSQL3 unit tests:
I don't know if failing tests are Delphi 2009 related (I didn't look them with debugger yet), but if they are, maybe is best to omit support for Delphi 2009 compiler (sooner or later I'll switch to newer version
, but for now I'm stuck with D2009
), because is buggy in areas you use most (this object, record issue) .
List of failing tests:
1.4. Cryptographic routines:
! - Base64: 2 / 11,994 FAILED
Total failed: 2 / 12,618 - Cryptographic routines FAILED
1.6. Synopse PDF:
! - TPdfDocument: 2 / 4 FAILED
! - TPdfDocumentGDI: 1 / 3 FAILED
Total failed: 3 / 7 - Synopse PDF FAILED
2.1. Basic classes:
! - TSQLRecord: 4 / 42 FAILED
Total failed: 4 / 245 - Basic classes FAILED
2.2. File based:
! - Direct access: 2 / 10,132 FAILED
Total failed: 2 / 618,271 - File based FAILED
2.3. File based WAL:
! - Direct access: 2 / 10,132 FAILED
Total failed: 2 / 618,271 - File based WAL FAILED
2.4. Memory based:
! - Direct access: 1 / 10,131 FAILED
! - TSQLRestClientDB: 2 / 615,382 FAILED
Total failed: 3 / 644,543 - Memory based FAILED
2.5. Client server access:
! - TSQLite3HttpClient: 1 / 3 FAILED
Total failed: 1 / 15,048 - Client server access FAILED
Synopse framework used: 1.13
SQlite3 engine used: 3.7.6.3
Generated with: Delphi 2009 compiler
Time elapsed for all tests: 52.55s
Tests performed at 2.6.2011 12:47:56
Total assertions failed for all test suits: 17 / 5,384,675
Hi, again some problems at least in Delphi 2009.
I compiled Main Demo, but I could not use it properly, because only "Audit trial" tab was created and two Access Violation has been reported.
I looked with debugger where it stops and I saw that it has some problems with TSQLRibbon creation.
The problem is with TFileRibbonTabParameters object (keyword, not instance
) which is derived from TSQLRibbonTabParameters.
When I combine fields from TSQLRibbonTabParameters with TFileRibbonTabParameters (this was enough, no need to change to record type, but inheritance is gone this way) all works fine.
Could you look through what could be an issue and how could be solved in general way.
In this way as you did, I'm assuming that this could be done only with object keyword, to have declarative way of UI definition and inheritance of common fields.
Some thoughts:
I think that such areas which are not performance critical is better to design with classes (avoiding problems as this in every corner
), even if this means different way of UI creation.
Maybe is better that UI related "elements" (as is TSQLRibbonTabParameters) should be in some other unit (e.g. SQLite3UICommons) and not to be referenced directly with SQLite3Commons unit as is in constructor TSQLModel.Create(TabParameters...),if not for other reason, just for clean separation sake.
Hi, I didn't know where to post this small error (should I open ticket as I did for 6593f0fbd1 in similar case or ?). I post it here, because is somehow related with provided pas units with Delphi 2009 (unicode), but it has nothing with object issue
.
In SQLite3i18n.pas at line 2872 and 2905 typecast to PAnsiChar should be done to be compilable, because default for MakeIntResource is not any more PAnsiChar in Windows.pas.
...
EnumResourceNamesA(HInstance, PAnsiChar(RT_STRING), @CB_EnumStringProc, PtrInt(@CB_EnumStringValues));
...
I'm assuming that you are doing ExtractAllResources with your Delphi 7
.
Anyway, many thanks for your excellent framework.
I'm enjoying learning it (through trying to make useful app) bit by bit (now I'm on i18n area as you see), sometimes is hard to understand some practices, but on the end I always reach the goal with help of your superb documentation in code and generated one.
The Delphi 2009 compiler is broken with the object keyword.
...
Did you install the latest fixes for Delphi 2009?
Yes, I have the latest fixes for Delphi 2009 (to the update 4).
I do updates from your repository at least once or twice on month, so I'll report if there would be more errors of this kind.
The code is not compilable under Delphi 2009 from version 2011-04-06 19:25 [a286d5c455] • added TMemoryMap ...
[DCC Fatal Error] SynCommons.pas(2874): F2084 Internal Error: DT5830
I changed the code to be compilable, but I don't know if this is the way you want it
:
{$ifdef ISDELPHI2009}
TMemoryMap = record
{$else}
TMemoryMap = object
protected
{$endif}