Les offres sont destinées aux clients commerciaux et industriels.
Tous les prix sont nets.
Grille tarifaire complète.
Vous n'êtes pas sûr du choix de votre édition ? Visitez notre tableau Comparatif des éditions
Sisulizer 4 is a payés mise à jour recommendée pour tous les clients de Sisulizer 1.x, 2008/2010 et 3.
Vous utilisez encore Sisulizer 1.x, Sisulizer 2008/2010 ou Sisulizer 3?
Il est temps de mettre à jour à la version 4 pour profiter des nouvelles fonctions des versions 4.
Version 4 Build 374 libéré
30.11.2018
La nouvelle version a de nouvelles fonctions. [plus]
Tutorials
5.3.2019
Tutorials updated [...]
.NET Support updated
14.6.2018
New in May 2018: [...]
Sisulizer 4 Build 366
1.3.2017
Build 366 - support for Visual Studio 2017 [...]
10 Years Sisulizer
5.8.2016
Celebrate and save Big. [...]
portée clients internationaux avec le logiciel dans leur langue
pour localiser leurs interne logiciel dans les filiales internationales
construire multilingue logiciel personnalisé pour les entreprises de leurs clients
comme Les fournisseurs de services de localisation parce que c'est l'outil de localisation de leurs clients
pour localiser le logiciel à gouvernement Agences
À enseigner les logiciels localisation dans les universités
pour la localisation de logiciels sur électronique Dispositifs
Traduction de logiciels pour biomédical Matériel
pour localiser le logiciel dans la Mining L'industrie
créer un logiciel mulitlingual pour mécanique Ingénierie
This document describes the basic steps that you should perform if you want to change you application fully Unicode enabled.
You do not have to change you application to Unicode application if you plan to localize it to Asian languages. A standard Ansi Delphi application can be localized to Asian languages just fine. However if you want to run you application in Japanese on Western Windows it has to be a Unicode application. Otherwise all strings will show incorrectly as mojibake strings.
If you want to localize your application to a language that has not code page support such as Hindi you have to make you application Unicode enabled.
Before you start changing you application from Ansi to Unicode carefully think if you or your customers have a need to run your application on different languages than their Windows or you need to localize for language that has not code page support. Remember that most western languages use the same code page and are compatible to each other. This means that you can run German application on French or English Windows and vice versa.
When you write properly internationalized code you have to change the default behaviors of each form and frame. This is why you better derive an abstract form from TForm and derived all your forms from this form. Do same form frame. This makes it easy to initialize the form in the constructor of the base form.
Current VCL components do not support Unicode. The reason is that every string property is type as String and not WideString. In order to make your application fully Unicode enabled you can not use the standard VCL components such as TLabel, TEdit, etc. Instead you have to use Unicode enabled controls. This will be changed in Delphi 2008. Currently there are two Unicode enabled component libraries. They are:
Library | URL |
---|---|
TMS Unicode Component Pack | http://www.tmssoftware.com/tmsuni.htm |
LMD ElPack | http://www.lmdinnovative.com/products/lmdelpack/ |
Both component libraries provide full set of Unicode enabled components. TMS components names and properties are almost identical to the original VCL components so it is easy to convert existing Ansi forms form Unicode forms. ElPack component names are a bit different so converting is little bit harder.
In many cases you have an existing project that you want to convert to Unicode project. At first replacing all existing components may seem very complicated but it is actually very easy. This how it is done.
If you use TMS controls change the base form of each form from TForm to TTntForm. If you use ElPack add TElFormCaption to each form.
Keep all internal data in Unicode. This means use WideString instead of String whenever you handle strings.
Keep in mind that VCL automatically converts WideString to AnsiString. This will make some of all data to be corrupted if it contains above ASCII character and the system code page of your Windows does not match the default code page of the string data.
Sometimes you have to use Ansi string. Use AnsiString instead of String. This makes it easier to pinpoint the placed that have already been checked. Whenever you see String variable you have to decided if you change this to WideString or AnsiString.
Handle all file names as WideString. Use the dialog components and system functions of your Unicode library instead of the standard VCL components and functions. For example if you had
if FileExists(fileName) then begin ... end;
Change it to (if you use TMS)
if WideFileExists(fileName) then begin ... end;
Whenever you call WIN32 API check if there is a Unicode version of the API. The Unicode version has the same name except its has W at the end of the function name. For example if you has the following code
function IsFileReadOnly(const fileName: String): Boolean; begin Result := FileExists(fileName) and ((GetFileAttributes(PChar(fileName)) and FILE_ATTRIBUTE_READONLY) <> 0); end;
Change it to
function IsFileReadOnly(const fileName: WideString): Boolean; begin Result := WideFileExists(fileName) and ((GetFileAttributesW(PWideChar(fileName)) and FILE_ATTRIBUTE_READONLY) <> 0); end;
Following these simple steps you can easily change you existing Ansi application into Unicode application.