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.prjupdate 'Project'-'Options'-'Macros' according to your installation.

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.

You do not have the required permissions to view the files attached to this post.

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?

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.

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.

EgonHugeist wrote: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 wrote: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.

mse wrote: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?

mse wrote: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.