With effect from Adelia Studio 11, you can generate Visual Adelia, Adelia Web and Adelia Mobile applications in Unicode.
Adelia complies with the UCS-2 standard for double-byte coding of fixed-width characters, which makes it possible to represent 65,535 characters compared with a mere 255 using standard single-byte coding.
Using Unicode offers many benefits:
Enhanced support for multilingual applications (including the ability to represent characters from several alphabets in the same application),
Reduction or total elimination of problems involving code page configurations and conversions between third party components such as the client/server Middleware and the database,
Compatibility with Windows XP / Vista themes: you must include the following lines in your application's manifest file.
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' />
</dependentAssembly>
</dependency>
Restrictions on use
Unicode and ANSI versions of generated applications cannot communicate with each other (as they run with different runtimes). It is therefore not possible to call an ANSI program from a Unicode application or vice versa. The complete program chain must be compiled with the same parameters. This also applies to Web applications. In an AS/400 server part only, you can call an ANSI program from a server part compiled in Unicode (CALL... *NON_UNICODE).
Crossed EXECUTE_CMD instructions are permitted, however.
The native file access instructions (CHAIN, READ, UPDATE, CREATE, DELETE...) are not authorized in programs generated in Unicode.
You can call a DLL function that uses ANSI parameters from a Unicode application (using the CALL_DLL *NON_UNICODE instruction). The reverse is not possible, however.
If you have developed your own interface DLL, it can be used in three ways:
- call it in ANSI mode (CALL_DLL *NON_UNICODE), if permitted;
- recompile an all-Unicode version of the DLL (which will not be compatible with ANSI applications);
- provide a version containing both ANSI and Unicode implementations of functions, in which case, you can simply add the suffix "$W" to a function name for the Unicode version, with the Unicode library loader searching for "FunctionName$W" first before trying "FunctionName".
In this case, it will be possible to use the DLL with both ANSI and Unicode applications.
Note: Calling an ANSI DLL function from a Unicode application (without the *NON_UNICODE flag), or calling a Unicode function from an ANSI application is very likely to cause the application to malfunction or crash.
Notes:
Although the Mobile and Java (VISUAL or WADELIA) clients were already in Unicode in earlier versions, there is a reason for generating applications in Unicode mode: in the previous version, server modules were generated with single-byte coding, and Middleware communication also used single-byte coding (apart from communication from a Java client to a Java server).
A Unicode application can communicate with a non-Unicode database, but you may encounter conversion issues if you attempt to insert characters that are not supported by the database's code page.
A non-Unicode application can communicate with a Unicode database, but you may encounter conversion issues when reading characters that do not exist in the system's code page.