String Class

For better understanding of this class and its functions, reading the about unicode and character encoding article is highly suggested.

Unicode support
This class adds support for almost any type of character encoding known to Windows. You can create SBCS or DBCS ANSI, MacOS, ISO, or Unicode strings.
You can easily convert from one encoding type to another, and on the fly append, insert, search for or replace substrings - even if the target's and the source's encoding types are different.

Import / Export
Load / save ANSI, MacOS, utf-7, 8, 16, or 16be unicode encoded files.
Copy from / paste to clipboard unicode, or ANSI strings, with respect to the string's locale.
Drag'n'Drop a string's data to any OLE application.
Export to / import from various Director data types

String Operations
With more than 100 commands, ranging from simple find and replace to advanced methods like selecting an HTML or XML tag, all you wanted to do and more (far as strings are concerned) is most probably covered. With the user of this class, your apps will be much faster and your scripts simpler and cleaner - less lingo code.

Compatibility
Most of the basic Director's string properties (e.g. char, word) and commands (e.g. put into) are supported by the new string object, in order for your scripts to be backwards compatible, should you decide to replace director's string objects with objects of this class in existing projects.

Performance
Creating a new xStr object is slower than creating a native Director string - this has to do with the way Director handles external objects.
From there on, you can expect a significant performance increase in almost all string functions, when comparing them with their Director equivalents. In certain cases, the difference can be measured even in times x.

References - Bringing the power of C++ pointers to Director.
Working with references can boost a movie's performance to a professional level. Keep in mind that under the hood, Director is a C++ app - one that sacrifices performance for stability. Going for speed is now an option. Working with references is quite simple - and safe as well, long as a couple of rules are followed.

Dot Syntax
The dot syntax used in this class is perhaps as important as the long awaited unicode support. You can use dot property-like commands to select an area of the target object, and then expand, shrink, move, modify the selection at will. Xtrema introduces an inheritance model for the dot syntax, which allows really lengthy and complex commands to be executed from a single line. This feature, along with the use of references can help you create extremely fast and memory efficient parsers. And all that without the need to use variables holding offsets in your code.

Displaying Unicode Strings
Though the Xtra can load / import / create / modify / save / export unicode strings, displaying the strings in is an issue, since the current Director's version text/field members do not support unicode strings.
A new text member is being designed, that will be able to display unicode text.
Until the completion of the new member, the 'toSL' command can be used to convert a unicode string to a list of ANSI strings that Director can display. This command can also be used to create MacOS - encoded text content.

Using Unicode Scripts
For using unicode script in your movies, have a look at the xtrLsEdit app, at the downloads section.

Known Issues

The output of a xStr in the message window, unlike Director's strings, will not be encloded in quotes.
Director will not perform string comparissons on xStr objects included in lists, when performing list searches (e.g. myList.getPos('someString').
A new list class, backwards compatible with Director's list/propList, is being designed, that will add support for xStrs as seekable list entries, along with various other enhancements. Soon as the new class is finished, all commands returning Director's lists will be returning xLists instead.
When Director requests the string representation of a xStr object, any '%' characters of the xStr will be lost (Director/XDK issue?). To avoid this issue, use the .string property to create and return a Director string when you need to use a xStr's content as a Director value. Using the .string is also faster than using the string representation (XDK issue)
E.g. _s("10%")&&"water" will return "10 water".
Use _s("10%").string&&"water" instead.
This may look bad, but it only affects cases when you are appending xStrs to director string objects. The only thing you have to remember to never face the lost '%' issue is to always use the .string property to instruct the Xtra to generate a Director string, instead of treating the object as a Director string. [ At least until the new XDK is released ]

Code Pages
All ANSI code pages are supported by default by Windows 2K or newer. To add support for aditional code pages (e.g. Mac code pages), go to
ControlPanel>RegionalOptions>Advanced, and select the code pages you want to add support for.