I agree.
Int64/UInt64 is absolutely necessary today. More important than a 64-bit compiler (even a 32-bit one), it’s even more important than uString. We’ve managed without that support until now.
1 Like
I would disagree.
There’s a large number of fixes and improvments. the extra wide template prompt windows are almost worth it by themselves. Being able to spread the IDE over 2 monitors is another one. The ODBC improvments and fixes are well worth it for me. Plus the new classes and templates. I use the SourceClass template quite a lot.
Going back to C6 feels very limiting.
My opinion of corse 
1 Like
LOL, I haven’t written an app that uses a dictionary or a template in the last 15 years. But I can quite understand that I’m the odd one out
It’s been a while for me too. But the SLN paradigm is a lot nicer than the C6 PRJ way, IMO.
But I definitely liked C6 until I got used to 10. But I do miss “shrink wrap”. That’s a good feature that didn’t make it to C7 and beyond.
3 Likes
I love writing classes, but could never imagine creating screens and full GUI system w/o a DCT and using the IDE and Templates. - Kudos to you!!
When I had my desktop, I ran the new IDE over 3 monitors to see what it was like and it meant I needed a bigger mouse mat and bigger desk to move the mouse pointer. I think also started to move the Repetitive Strain Injury from my wrists to my shoulders and elbow.
I went back to running it on a single monitor, even though I had nvidia graphics cards which could simulate different types of monitors at the hardware level.
I only used the C11 IDE for my template builder, because it was a template that was simply too big and would hit the C6 16bit limits. I’ve never seen or heard anyone hit those limits…
For coding apps I still prefer C6 but I can copy them into the C11 IDE for compiling as a release copy, if I ever get to release any software…
I’m guessing you are hand coding your classes?
I tried @Bruce Object Writer the other day. I see how he’s created a template to write classes working within the limits of Clarion, but I wouldnt have written a Template for writing Clarion classes that way.
My test or condition for writing a template, is its got to work and be intuitive enough for someone who has never seen it before or have dementia to be able to use with just a TLDR.
I think we have limits as to what is or can be remembered at the time its required, and hackers exploit those little known nuggets of info.
I would love to be able to change the mouse pointers in the Window formatter.
It trips me up all the time.
Although I’ve been able to figure out some of the other changes like colour with the IDE as seen here.
Hi Rich.
Just FYI while Object Writer was useful in the early days of class writing (before the syntax was familiar) it quickly became superfluous.
These days (and i guess for the last 20 years or so) we’ve written classes directly in the editor without the template.
And because the template generates CLW and INC files anyway, it was trival to just stop using the app and edit the files directly.
Other details (like the management of compile directives, generation of EXP files and the like is done by CAPE01.TPW and CAPE02.TPW which are helper code included in all the class based templates.
2 Likes
I dont dispute, once one has become a seasoned class writer, its a piece of cake writing a class by hand in the editor, but for the occasional class writer, I think a template would be quite useful, for those extra little caveats, and if working in multiple languages, again I think a template that can write classes for a language would be useful. Obviously you are predominantly writing in the Clarion language.
And I’m not knocking your effort, I’m just saying I would have done it differently, but there we go I cant show this because my backups got wiped and I’ve lost a lot of work.
Hey ho, such is life.
Creating the new IDE in csharp might now be seen as a not so great move… If the APP gen is a CPP dot net marshalled invoke from Dot Net.. (DOT NOT) then maybe the move from C6 should have been a QT IDE rewrite…
Its all starting to look a bit Bits.and bytes and ..
Just clarion the ill fated Clarion sharp… but who would have though microsoft would be back porting modern GUI to fit into win32…
Clarion 12 fixing some bigs and moving along to utf-16 support might be as good as it gets…
Just keep the big stack collection working…now where is that new resize for there any screen solution…much has stalled im afraid…
Some coders dont even use the IDE do they? MG for instance?
dont panic its been like this before… you wont see the developers who have DOS 1 and 2 versions in the cupboard in brand new looking boxes panic…
we recently had a 20 year old sony TV restored… goes well…
Another blog… presenting the documentation of UString.
5 Likes
In the Common Pitfalls section is this:
Pitfall 2: Buffer Size Confusion
! WRONG - Allocating based on character count for bytes
Name USTRING(50)
Buffer STRING(LEN(Name)) !Too small! Only 50 bytes, need 100
! CORRECT - Use SIZE() for byte allocations
Buffer STRING(SIZE(Name)) !Correct: 100 bytes
@RZaunere IMO what’s also wrong about that (another common Pitfall) is the change to the Null Terminated U String is LEN(Name) will be Zero?
The initial value of the old STRING(50) was 50 spaces so LEN = 50 and the code worked. I would expect the initial value of a UString() to be <0,0>. So LEN=0 it’s an invalid string, not half the size.
The change to Null Terminated Strings has some possible pitfalls. That Pitfall example (and others) should use UString(50 +1) as the declared size as a reminder of the need to allow +1 for the Null.
If your going to use USTRING(LEN(xxx)) then code with +2 as USTRING( 2 + LEN(xxx)) to allow +1 for trailing Null and +1 incase LEN()=0.
Hopefully SV will adapt the proper use of TextOut in the EMF’s whenever that happens.
All TextOut commands should be in Unicode - even if it’s Ansi.
@RZaunere the post shows Size() returns the Bytes in the the new UString e.g. SIZE(UString(20)) returns 40 bytes.
For calling the Windows Wide String W API that pass buffer size those functions expect it in number of WChar (UShort’s) not Bytes. So SIZE() will not work.
For example the wide GetUserNameW() passes a UString and its Size in USHORT’s
BOOL GetUserNameW(
[out] LPWSTR lpBuffer, pointer to the buffer to receive the user's logon name
[in, out] LPDWORD pcbBuffer ); size of the lpBuffer buffer in TCHARs
Calling that using the new U String cannot use Size():
ULEN EQUATE(256) !max size of name
UsrName USTRING(ULEN+1)
LenName LONG
LenName = SIZE(UsrName) !Wrong is 514
LenName = ULEN + 1 !Right is 257
GetUserNameW(UsrName, LenName)
It could be done with LEN(), but only if the USTRING is filled with spaces?
LenName = LEN(UsrName)+1 !Wrong is 1 because UsrName='' ?
UsrName = ALL(' ')
LenName = LEN(UsrName)+1 !Correct with init all spaces
GetUserNameW(UsrName, LenName)
One choice is to change SIZE() to return size in UShorts for USTRING and BSTRING instead of Bytes. That works well if one USTRING is based on the size() of another, but not if you are mixing with Byte based types.
Another idea is to define new size functions
‘SizeB()’ always returns in Byte’s same as current Size()
‘SizeC()’ for B / U String size in UShort’s else does Byte’s
Guess if look at how other languages handle it, like maybe Delphi or VB.net.
Does MAXIMUM() work with UString’s? That would return the defined dimension not Bytes. But I don’t think that’s a compiler directive.
Edit: help on String Slicing says No
The MAXIMUM procedure does not operate on the implicit dimension [of Strings], you should use SIZE instead.
With You UString(31) does SIZE(You[1]) of a 1 character slice return 2? Then it would work to code:
LenName = SIZE(UsrName) / SIZE(UsrName[1]) !is 514/2=257 that's right
GetUserNameW(UsrName, LenName)
And changed to a STRING calling the “A” function works. This is seen often in C++ API code, especially with “T” Strings.
When calling Win API’s, one could use SIZE(name)/2. Maybe a bit clumsy, but perhaps not worrying over.
My main complaint with the blog is the use of the word “character”, but as a first approximation of the truth it’ll do (for english readers.)
Kinda like saying “the earth is round”. It’s not true, but a simplification which is “mostly true”.
In the common case of names and addresses (where most of the need for unicode exists), its probably close enough, and the length chosen for those USTRINGs is arbitrary anyway.
In cases where emojis are likely (like comment or message fields) then be aware that each emoji counts as “multiple characters” - perhaps as many as 6. But most apps will have very few places where emojis are appropriate.
I suppose Cstring is for APIs that accept ANSI and UString is for APIs (W) and they are two separate paths.
I agree with you on the LEN() discussion — for names and addresses, treating “character” as “UTF-16 code unit” is a reasonable simplification, and in most business apps it’s close enough to the truth.
My bigger concern is actually a layer below that: the current state of the editor.
At the moment, the Clarion IDE still behaves as an ANSI editor. If non-ANSI characters (especially emoji) are pasted into a source file, the IDE silently switches the file to UTF-8 with BOM. That immediately causes compiler errors because the compiler doesn’t tolerate a BOM at the start of the source.
USTRING itself is fine — it’s a runtime and language feature — but there doesn’t seem to be any information yet on whether the editor will become Unicode-aware, or whether the expectation is still “ANSI source, Unicode only inside u’…’ literals”.
That distinction matters in practice, especially now that more developers are using AI tools to generate code. Emojis or other non-ANSI characters can creep into comments or strings very easily and break the file without any warning.
So my concern isn’t really about LEN() being “close enough” — it’s about whether Clarion 12 plans to address the editor/tooling side so Unicode support is safe end-to-end, or whether the current ANSI-editor constraints still apply.
Even a clear statement of intent (“the editor remains ANSI for now” vs “Unicode editor work is planned”) would help set expectations.
Anyway, just a thought.
Mark
1 Like