Zeoslib for MSEide+MSEgui 3.1

[mse]

Hi,
Because MSEgui 3.0 has own db.pas and classes.pas the Zeoslib components had to be removed from MSEide 3.0.
A patched Zeoslib which works with MSEide+MSEgui is here:
https://gitorious.org/mseuniverse, repository zeos-msegui, branch mse.
MSEide+MSEgui with Zeoslib support is here:
https://gitorious.org/mseide-msegui repository mseide-msegui, branch master.
There is a predefined project in order to build MSEide with Zeoslib support:
apps/ide/mseide_zeos.prj
update 'Project'-'Options'-'Macros' according to your installation.

Martin

[EgonHugeist]

Hi Martin,

thank's for constribution! Didn't check your diffs right now. Could you attach a *.diff file? Than i'll apply the changes. Btw. which Zeos did you use?

[mse]

See attachment. Diff is from svn trunk r2793, I updated the git repo on Gitorious. Please check ZeosLazarus.inc around line 95, we both made changes there it seems.

[EgonHugeist]

Martin

leider konnte ich das patch so nicht anwenden, da aller Anfang in \testing-7.2 geschieht. Habe alles manuell anhand der diff-Datei eingepflügt. Könntest du mal 7.2 auschecken und schauen, ob es funzt?

Thank you for you work. Hope i did everything right to support YOUR MSEgui-RAD-IDE too! Keep up this great work. FPC goes UNICODE!

[mse]

It compiles and runs with the attached patch. There are problems with the encoding of the sources, I suggest to make them strictly ASCII (no characters > 127) and use the #nnn notation for non ASCII characters in order to have encoding independent sources. MSEide has the function RightClick-'Convert to Pascal string' for the purpose.
Updating string fields does not work, FormUpdateStatement() in src/dbc/ZDbcGenericResolver.pas:849 always returns an empty string for ftString fields, I'll have a look later.
I pushed testing-7.2 to Gitorious https://gitorious.org/mseuniverse zeos-msegui, branch testing-7.2.
My changes are in branch testing-7.2mse.

[EgonHugeist]

Thanx, Martin.

Patch applied R2818 \testing-7.1 (SVN)

In the previous episode you told me the default string is UnicodeString for MSEgui 3.0. Did you check the UNICODE define? It might be bossible the RowAccessor works incorectly because of PWideChar/PAnsiChar difference. How did you mange the default UnicodeString for FPC2.6?

[mse]

MSEgui uses msestring=UnicodeString=utf-16 for all GUI strings and for record buffer in the MSEgui datasets. Instead of pwidechar on a datablock with leading count cardinal we use reference-counted UnicodeString in all buffers. For "alien" datasets, for example the datasets from FCL or Zeoslib the tmsestringfield converts from/to AnsiString to/from msestring either from current system encoding or from utf-8 if the utf-8 flag is set. This conversion probably could been simplified for the new Zeoslib 7.0+ I plan to check that later.
MSEgui does not use string=UnicodeString setting of FPC trunk and I absolutely don't like the FPC trunk code page aware AnsiString which Embarcadero doesn't like too it seems.
The problem of the failed update is possibly in the TZRowAccessor.CopyBuffer() procedure which always returns empty strings for ftString in the MSEgui Zeoslib 7.2 testcase. It works with the patched Zeoslib SVN trunk Version. I am investigating.
Edit: nope, got it.

Code: Select all

diff --git a/src/dbc/ZDbcCache.pas b/src/dbc/ZDbcCache.pas
index 5a975f2b8e2369321f1b87eb924c219bf31c6e9e..1d57e6b637e69cbf40aafc63d34b71be8229a6ab 100644
--- a/src/dbc/ZDbcCache.pas
+++ b/src/dbc/ZDbcCache.pas
@@ -3888,8 +3888,8 @@ end;
 {$ELSE}
 var S1, S2: ZWideString;
 begin
-  System.SetString(S1, PWideChar(ValuePtr1^)+PWideInc, PCardinal(ValuePtr1)^);
-  System.SetString(S2, PWideChar(ValuePtr2^)+PWideInc, PCardinal(ValuePtr2)^);
+  System.SetString(S1, PWideChar(ValuePtr1^)+PWideInc, PCardinal(ValuePtr1^)^);
+  System.SetString(S2, PWideChar(ValuePtr2^)+PWideInc, PCardinal(ValuePtr2^)^);
   Result := WideCompareStr(S1, S2);
 end;
 {$ENDIF}

Please apply the uses chunks of the previous patch too, order of Classes and mclasses is important, mclasses must be after Classes.
Thanks, Martin

[EgonHugeist]

Thank you Martin. Oh it was a non Windows issue..

Patches applied. R2828 \testing-7.2 (SVN)

Nice to have Zeos running for MSEgui too. If you want, than i can grant you commit rights. Just to keep Zeos running on MSEgui.

Accordingly the UnicodeStrings vs TZWideRec.

This is newly introduced code to have better performance. I'm trying to avoid ich localizing of the strings where ever i can. Inbetween i could speed up fetching speed for the Unicode-IDE's x3 and and a loads for the Ansi-IDE's including FPC. Also does the update, delete and insertiation speed perform loads better. 7.0 and 7.1 have been my first approaches to get all IDE's running. Now i optimze all prozesses, after the "how to do" is clear. There is still not top of data reched yet.

As i wrote in the geman forum: My benchmarks for FPC and direct working with the UnicodeStrings have been a speed killer. There are a set of functions in ZSysUtils/ZFastcode which do highly perform with Delphi, much faster than the RTL function as long i don't play with the UnicodeStrings. Therefore is was forced to work in local AnsiString/RawByteString and move the results to UnicodeStrings. Faster than FPC RTL but absolutly NOT compareable with Delphi in this case..

Let us hope they will get a better performance running with FPC2.7 propably 3.0(if stable)+UnicodeString.

[mse]

Nice to have Zeos running for MSEgui too. If you want, than i can grant you commit rights. Just to keep Zeos running on MSEgui.

Probably no good idea because I can test on FPC only...
I'll test Zeos MSEgui compatibility from time to time and provide patches.

Accordingly the UnicodeStrings vs TZWideRec.

This is newly introduced code to have better performance. I'm trying to avoid ich localizing of the strings where ever i can. Inbetween i could speed up fetching speed for the Unicode-IDE's x3 and and a loads for the Ansi-IDE's including FPC. Also does the update, delete and insertiation speed perform loads better. 7.0 and 7.1 have been my first approaches to get all IDE's running. Now i optimze all prozesses, after the "how to do" is clear. There is still not top of data reched yet.

That are about the same intentions I had when I forked SQLDB. But my task was simpler because I need to serve the UnicodeString based MSEgui only.

As i wrote in the geman forum: My benchmarks for FPC and direct working with the UnicodeStrings have been a speed killer. There are a set of functions in ZSysUtils/ZFastcode which do highly perform with Delphi, much faster than the RTL function as long i don't play with the UnicodeStrings. Therefore is was forced to work in local AnsiString/RawByteString and move the results to UnicodeStrings. Faster than FPC RTL but absolutly NOT compareable with Delphi in this case..

Let us hope they will get a better performance running with FPC2.7 propably 3.0(if stable)+UnicodeString.

There probably is a misunderstanding. FPC had UnicodeString (=reference counted utf-16 string on all platforms) before Delphi. The first FPC WideString implementation was reference counted on Windows. MSEgui based on that string type. Later Florian made FPC Windows WideString Delphi compatible (utf-16 encoded not reference counted OLE-String) - against my loud opposition I may add.
Later when Delphi introduced the original FPC WideString as UnicodeString FPC did the same. What now has been implemented in FPC trunk is the codepage aware AnsiString, again against my even louder opposition. It should be noted that Embarcadero removed that string type already in their new LLVM based compiler.
Ein Trauerspiel...

[mse]

Patches applied. R2828 \testing-7.2 (SVN)

Compiles, runs and works with FPC fixes_2_6 and MSEgui 3.1, thanks and congrats. :-)

[EgonHugeist]

Probably no good idea because I can test on FPC only...
I'll test Zeos MSEgui compatibility from time to time and provide patches.

Thanks in advance, Martin.

There probably is a misunderstanding. FPC had UnicodeString (=reference counted utf-16 string on all platforms) before Delphi. The first FPC WideString implementation was reference counted on Windows. MSEgui based on that string type. Later Florian made FPC Windows WideString Delphi compatible (utf-16 encoded not reference counted OLE-String) - against my loud opposition I may add.
Later when Delphi introduced the original FPC WideString as UnicodeString FPC did the same. What now has been implemented in FPC trunk is the codepage aware AnsiString, again against my even louder opposition. It should be noted that Embarcadero removed that string type already in their new LLVM based compiler.
Ein Trauerspiel...

Uh that i didn't know. And indeed except of displaying the characters the UnicodeString makes trouble here and there (mainly on the streams). Buth thanks for these details, i didn't know them.
Accordingly the missing refcount for the WideStrings. AFAIK is the WideString allocated in gloabal heap. So having a local (compiler provided) should be faster, IMO.

The codepage agnostic... A loads of people will have some problems, otherwise why having an alias like UTF8String/AnsiString if nothing takes control about encoding. Apropos encoding: How do you manage the ansi to wide moves? Did you add unit cwstring?

thanks and congrats. :-)

No THANK YOU, Marktin. You did this job. I'm pretty happy to support another IDE. Peoples have there custom and having Zeos running on MSEgui could point them to your IDE too instead of UTF8-LCL.

Michael

[mse]

AFAIK is the WideString allocated in gloabal heap.

FPC WideString is OLE-memory on Windows. On all other platforms WideString = UnicodeString.

Apropos encoding: How do you manage the ansi to wide moves? Did you add unit cwstring?

Yes, MSEgui has a modified cwstring unit.