Unicode mode for methods

Home

4D v15

4D v15 allows you to save 4D method code strings in Unicode:

In databases created with 4D v15 and later, the method code is automatically saved in Unicode
In databases converted from a previous version, the new Save methods as Unicode Database Settings compatibility option allows you to switch to Unicode mode:

Note: If you modify this option, you need to restart the application in order for the change to be taken into account. You can check or uncheck this option at any time; only methods saved subsequently are affected.

Why save code in Unicode?

In previous releases, 4D method code strings (formulas, variable and method names, comments, etc.) were saved using the current local encoding. This encoding could cause issues, especially when 4D code was shared between developers from different countries: for example, if a French developer wrote some 4D code that included accents and then sent the database to an English developer, these accents would be lost. Serious issues could also occur with code written on Japanese versions.

Saving methods as Unicode resolves all these types of issues and makes it possible to exchange 4D code containing specific local characters.

We recommend that you enable the Unicode mode option for methods as soon as possible in your existing databases, especially if you work in an international environment.

Implementation note: This new feature applies to the language itself and its interpretation. Some 4D editor windows, such as the Property list, still use current local encoding and therefore may display certain strings incorrectly. However, this does not affect code execution.

Compatibility

Saving 4D methods in Unicode (in a new 4D v15 database or in a converted database with the Save methods as Unicode option selected) is transparent for users.

However, necessary internal changes have resulted in a deep modification of pointer representations in 4D code. "New" pointers are more optimized internally and also support extra features such as 2D array elements (see RESOLVE POINTER).
To maintain compatibility with previously compiled components and plug-ins, a new pointer data type has been added to the 4D language, instead of simply replacing the existing type. This new type is handled transparently in your applications. Note however that:

RESOLVE POINTER now returns -1 instead of 0 in the fourth parameter for pointers to variables and single-dimension arrays.
Get pointer will behave differently regarding invalid variable names or extra spaces.