the new build covers a lot of territory and the link in the blog: “Open the full Unicode Tester Guide”
serves as the HELP for now:
there are several maintenance bug fixes but the bigger news is in new features including;
USTRING as a 1st class data type
BLOB fields available as a USE() var (no plumbing code needed, ADD/GET/PUT)
new TopspeedW driver, full Ustring and Blob,Unicode support
new data type mappings for MSSQL,ODBC,PG and Sqlite (nvarchar(#),nvarchar(max),varbinary(max) )
and lots more covered in the blog. There’ll be a follow-up blog covering updates to the DCT editor/Data Browser/Designers
I bet the runtime is going to be a bit bigger to handled the extra functions like Len() for WideString/Unicode.
Older IDE builds cannot open an .app that uses wide designer text.
Gonna have to upgrade.
Anyone know if the AppGen TXA/TXD files are going to remain Ansi or move to Unicode?
This answer’s my question I think…
Known limitation — embeds
Generated code from the native template engine is always ANSI. Non-ANSI text typed into an embed cannot survive as raw characters — write U'...' with unit metachars, or put the code in a UTF-8 INCLUDE file.
So perhaps the TXA/TXD will remain Ansi for now.
Known limitation
Imported USTRING screen picture defaults to @s20 regardless of column length — adjust by hand.
Imported how? TXA/TXD? Cut and Paste from one instance of the AppGen to another instance of the AppGen?
A template listing the fields to change manually will be handy.
If the TXA/TXD remains Ansi, then will this be updated in the future?
Looking like the AppGen will remain Ansi, for how long who knows?
Known limitations
MATCH:Regular and STRPOS narrow to ANSI today (byte-based regex). Match:Soundex narrows by design (ASCII phonetic algorithm).
Looks like @vitesse RegEx engine/class is safe for a while… (I still havent looked at it yet Geoff)
When reporting an issue
Most useful evidence: the exact text (as a U'...' literal or code points), the declaration (field / control / driver string), what you expected, what happened — and whether the same steps work with plain ANSI text.
actually the TpsW driver being tested externally is limited to 2Gb (for now) but the internal TpsW is extended to 512Gb (not suggesting I’d want to approach that total limit for ISAM any format), but it does mean that: devs approaching the 2Gb limit of the classic Tps driver have an easy way to extend; and the classic Tps driver supported 640mb blobs but that was actually also limited by the total file file size of 2gb, with the new TpsW driver blobs can be rather large before you hit the total file size limit.
One other useful bonus; the 2gb Tps classic limit had a weak guard on exceeding that limit which would result in file corruption, that’s fixed now with an error thrown before any corruption can happen
Hello Alexey,
The compiler is hybrid old/new with the goal of producing byte-identical binaries if narrow ANSI-only types/functions/code is compiled (zero regress compat. for existing code).
Your email to me about the import. of support for wide char<–>multi unit like-emoji handling was fortuitous, it made me look at the whole implement. from a better perspective in terms of req. support. I think we have achieved it in the ‘Clarion way’. email me if you have time to do some digging before the general release and we’ll get a pre-release out to you. the same offer to anyone who has both the time and the req. for it, but if I get swamped by offers to test don’t get mad if they are delayed response (I have no system in place for handling large response vol.)
Hi, Robert. Thank you for your answer.
The throwing of an error instead of causing a corruption is GREAT.
Even for ISAM, sometimes historical files may need to be mostly write once and accumulate records over time, so not much records or keys moving around. For those files, we are doing acrobatics to segment and handle the file in chunks of 2 Gb. To be able to have those few files as large as they can be (without the hassles of installing and handling a SQL) would be absolutely fantastic.
So basically the internal pointers and sizes have changed from 32 to 64 bits? Guess the RTL file procedures would need to take and return INT 64’s to use it > 2 Gb
That will actually play well with some of the new things we have in development and give us a chance to see how the new code does with some edge cases as well.