About strings and characters

version 2003

When 4D Plug-in API accepts or returns a string or a text, it can use Macintosh or ANSI characters sets, and a string can also be a Pascal string or a C string.

By default, as defined in 4DPluginAPI.c, 4D Plug-in API uses:

• When compiling for MacOS:

	ANSI C strings
	Macintosh characters

• When compiling for Windows:

	ANSI C strings
	ANSI characters

For specific needs, you can use the following routines to tell 4D Plug-in API that you want to send and receive Macintosh or ANSI characters, or if you prefer, to use Pascal or C strings:

	PA_UseMacCharacters
	PA_UseAnsiCharacters
	PA_UsePStrings
	PA_UseCStrings

Please remember to use it carefully. For Macintosh/ANSI characters, an error will result only in bad characters received by the user. But, with strings, confusing between a Pascal or a C string can lead to a system crash because of the null terminated C string and the length byte of pascal strings.

The problem may occurs more often when you use a C string when 4D waits a Pascal string. It could try to fill a buffer while it doesn't reach a null character

Internally, 4D works with Pascal Strings and Macintosh Characters. As the API takes care of the swap stuff in every call of the API that needs it, the Plug-in developer should keep its habits, working with ANSI C strings (usually under Windows) or Pascal strings (on Macintosh). If the API receives a Pascal string, it does not convert it before calling the entry point. If i receives C string, it converts it. This is transparent for the Plug-in developer.

Those settings are specific to the PluginAPI.c file. They do not affect other sources files of your project. Just be careful when developing a cross-platform Plug-in, using Pascal strings with MacOS and C strings with Windows.

If you use Altura to compile a project for Windows using MacOS Toolbox API, you should call PA_UsePStrings early in your project. For the characters sets, it depends of the way you use them, and specific calls may be needed.