For ULC applications, all strings are passed from and to the server as
Unicode (UTF-8) strings. However, Smalltalk uses the local code page
for processing strings. Before release 3.0, ULC processes all
String data with the assumption that it is Unicode data. On ASCII
platforms such as Windows (R), the English characters ('A-Z' among
others) have the same codepoints both in ASCII and in Unicode.
Therefore, most applications can send data in the local code page even though
the ULC client processes that data as if it were Unicode data. For
platforms that are not ASCII based, this does not work.
Before release 3.0, for platforms that are not ASCII based, hard
coded English strings in the server could cause problems because the string
data needs to be translated to Unicode before being transmitted to the
client. Also, the strings coming back to the client need to be
translated back to the platform codepage. This could cause characters
to be lost because the client could be in a different locale than the server
and the translation of certain characters cannot be made (This could occur
even with ASCII platforms where the locale of the server and client did not
match).
In release 3.0 ULC provides two new classes for processing Unicode
data, UlcUnicodeSBString and UlcUnicodeDBString.
All Strings and Labels generated by ULC and all string data stored in MPR
files are converted to these new data types (see Converting Strings to Unicode). The application programmer needs to be aware that
the UI Engine sends any string data back as Unicode strings. This can
cause some problems with hardcoded strings because String does not equal
Unicode string and therefore will not compare as equal with data received from
the client. (When writing your application, it is recommended that you
use MPR files instead of hardcoded strings). There are two solutions to
this problem:
For ULC applications written before release 3.0, see Running applications in Compatibility Mode and Migrating to Unicode.
Handling Strings in ULC applications