Developing OPC Client 1 with Lazarus (about character sets)

In fact, very early plan to do in the Lazarus inside, or in the actual application of time too tight need to use the OPC of the program with Delphi change, also used.

After the FPC3.0 also after lazarus1.6, its core to UTF8 comprehensive support, led to Delphi many procedures can not directly transferred to Lazarus inside. Knowing undeterred, OPC inside will use a lot of Pwidechar and olevariant this is difficult, itself technically not, but with the integration of Lazarus there is a lot of uncertainty.

The OPC client build process is simple

1. To establish a reference to an ActiveX server
2. Group manager through the server interface--build groups
3. Add "entries" to this group through the group's "tab manager", which is the industry---tag "label".
4. Now you can read/write read and write labels.
5. If you want efficiency, OPC provides the means of hosting, which is often translated as a "subscription." Build subscriptions in groups.
6. If successful, OnChange, AsyncRead, AsyncWrite (asynchronous read-write) will be implemented.

Every step of the period to pay attention to the release of resources! And every step has to deal with the string, attention to COM internal use of widestring, but the master of Microsoft in the design of the natural will be a lot of pointers, so the Pwidechar and the FPC string interaction becomes the main task. Key question string, not completely solved even if the build success can not display properly, let alone because of Lazarus internal conversion, basically is the construction is unsuccessful.

RTL,LCL default is UTF8 This is an advantage, but it is difficult to navigate, which also leads to a lot of lazarus1.2x before many solutions expire, such as SysToUTF8 and Utf8tosys, trace discovery

functionUtf8tosys (Consts:string): string;begin  {$IFDEF Utf8_rtl}Result:=s; {$ELSE}  ifNeedrtlansi and( notIsascii (s)) ThenResult:=Utf8toansi (s)ElseResult:=s; {$ENDIF}EndNote the conditional compilation {$IFDEF utf8_rtl}   in this face

Causes these procedures \ functions \ Methods Sometimes "invalid" is mainly the role of conditional compilation {$IFDEF utf8_rtl} , in fact, the last post mentioned in the FPC 3.0 Increase the-DDISABLEUTF8RTL Project compilation option so that the parameters are saved in the project. When the configuration is complete, the above statement can be executed to the {$ELSE} section.

The whole phenomenon of this let me annoyed for a long time, always can not clear the results, resulting in Lazarus program string output can not achieve the desired effect, with a lot of methods, and even doubt whether it is true to give up the UTF8 conversion unit, using the system self-function judgment. Fortunately, there are two items on hand. One has this parameter one does not, the result leads to the very different effect, certainly has one can accurately realize the design intention otherwise will not analyze-fortunately. Finally I looked at [Lazarus] UTF8 RTL for Windows only remembered.

After the direction is clear, the solution to the problem is to find concrete ways to deal with the string.

Our usual solution to Polechar is Pwchar (widestring (xxxstring)), in Lazarus Small Project example Project no problem, large, that is, the use of resources more likely to use the time has already been released. STRINGTOOLESTR (xxxstring) must be used.

The following process functions are obtained after integration

functionUTF8STRTOOLESTR (Constsource:utf8string): Pwidechar;varvs:string;beginVS:=Utf8tosys (Source); Result: =polestr (widestring (VS)); Result:=stringtoolestr (VS); ifResult =Nil  ThenResult:="';End;functionOLESTRTOUTF8STR (ConstSource:pwidechar): utf8string;varvs:string;begin  ifSource =Nil  ThenResult:="'  ElseWidechartostrvar (Source, VS); Result:=SysToUTF8 (VS);End;

Now the memory is too bad, make a record.

Developing OPC Client 1 with Lazarus (about character sets)