By request of Carl, here are Bob Z’s posts about C12 from the newsgroup server.
I can’t seem to find the original message so I’m repeating myself here:
There are two recent blog posts:
It seems like the old NNTP dBabble server software is showing its age (it was
last updated early 2004 and is not supported any longer).
A lot of users have been using ClarionHub and the cw-talk Discord group.
Robert
The ‘beta’ designation is specifically for the new USTRING data type.
Why USTRING exists: C12’s initial approach modified STRING to handle both ANSI
and Unicode. While existing STRING code remained rock solid, the Unicode
support didn’t meet developer needs. We tried hard to avoid adding a second
type, but the reality is that fully retrofitting Unicode into STRING would
require breaking changes that aren’t acceptable for production code.
What beta means: This gives you a safe testing window for USTRING without
risking your production systems. Test it, break it, and tell us what needs
fixing before it goes production.
The separation of string types is the right call - trying to make one type do
both jobs well would have forced compromises to both string types.
Robert
On Thu, Jan 8 2026 3:32 am, John de la Torre said:
Beta after gold? Was gold beta’d?
–
John de la Torre
CA, USA
We chose UTF-16 for USTRING because it provides the best balance for our
environment. Given our Windows codebase and integration with .NET/C#
components, UTF-16 gives us direct API compatibility without constant encoding
conversions. UTF-16 is the native encoding for the Windows API. Converting
between UTF-8 and UTF-16 at every OS boundary would add overhead and
complexity. UTF-8 is more compact for ASCII-heavy text, with a variable 1-4
bytes per character. But UTF-16 is a Fixed 2 bytes for most common characters
(BMP), and that results in a predictable memory layout.
Robert
On Fri, Jan 9 2026 1:11 pm, “Lee White (Lodestar Software)” said:
Petar,
But why UTF-16 ? UTF-8 is a standard everywhere in comunication, sql etc.
Windows uses 16 internally so seems the logical choice.
–
Lee White
On Fri, Jan 9 2026 2:48 pm, “sparky” said:
Tres kewl
Will we have commands similar to string slicing and/or SUB for these
Uboats… uh, UStrings?
Uboats… haha!
SUB, INSTRING for certain, string slices are WIP
The examples in the blog imply that the embedditor will accept non-Latin
characters (if tagged with a “u” prefix). True?
The Embeditor is the Editor in a wrapper, and the Editor already supports
Unicode, the “U” or “u” is required info for the compiler (which is also
updated to support Unicode)
Robert
On Fri, Jan 9 2026 2:43 pm, “Lee White (Lodestar Software)” said:
Robert,
https://clarionsharp.com/blog/clarion-12-beta-ustring-returns-ansi-unicode/
Are template prompts going to support Unicode???
not currently implemented into the template system
If so, are there functions available to handle entry if, for instance,
it is? Such as “knowing” at the template level if it’s Unicode?
not sure that I understand why you would need to detect Unicode characters?
The USTRING does support both ANSI and Unicode characters