News from CIDC 2017

We are back from the 2017 Clarion International Developers Conference, held in Orlando Florida this year.  I know it’s not possible for everyone in the community to attend the conference, so this post will cover topics that Diego and I presented.

Starting with Clarion 10 – we have a new build just about ready for release within a few days. It’s a significant build with over 150+ fixes/changes and new features.  I’ll post a link to the readme as soon as it’s finalized. Some of the new features were requests for new functionality in the H5 stack. Diego presented H5 in-depth, and quite a few developers were convinced that H5 has a place in their future.

On to H5 – H5 is now code complete. The combination of the AppBroker and your App on the server side, and Bootstrap+jQuery+HTML5 on the client, gives you the simplest path to deploy your App to phones/tablets almost instantly. You re-use 100% of your existing business logic, you customize the UI using CSS themes. And just by a copy/paste of Javascript code snippets you can extend your app to all kinds of new possibilities. Things like signature capture, geolocation, data graphing can be added for free. If you haven’t tried H5 yet, take 15 minutes and give it a try.

On to Clarion 11 – here’s a screenshot of a slide I showed during the keynote

C11 is the biggest update to the Clarion codebase since moving from DOS to Windows – the new internal classes are the base for the evolution of Clarion for many years ahead. I’ll do a separate post covering C11 with more details on what is coming. We think we’ll have C11 into alpha testing within a couple weeks!

On to Clarion.Net 4.0 – it’s been in use within the IDE since the first release of C10. And we released it to several developers who needed to update their production programs to support .Net 4. We plan on making a general release before the year end, and it’s likely that when we release C11 we’ll update it to .Net 4.5. We are supporting a new feature in the next release, during the compilation of the Clarion code we’ll generate C# code and project file (into a separate folder) that provides the exact same functionality as your Clarion code. That means for those who want to work with WPF or share code with a C# project, you can easily bring the code into VS.

On to mobile dev – over the last 2 years we experimented with just about every approach to mobile dev available. From pure native code solutions, to cross-platform C#, to hybrid apps using free frameworks like Apache Cordova or PhoneGap, and more.

Using the native code approach means you can’t develop for iOS without access to a Mac, period. And of course it means learning Objective-C or Swift, and Apple’s Xcode IDE. To support Android with native code you need to write code in either Java or Kotlin, and learn Google’s Android Studio IDE.

With a hybrid mobile approach you can code in a single language (Javascript) for both iOS and Android. But it has several drawbacks; while you can achieve a nice looking UI using HTML, you can never achieve a native look and feel for either platform. And as your app grows in size and complexity, it’s very likely you’ll run into performance problems.

When we set out our goals for mobile dev with Clarion these are a few factors we felt were critical:

  • Provide a (scalable) solution to deploy to mobile/tablets
  • Re-use unique Clarion knowledge/skills
  • Provide access to your database to any modern client app (Mobile/web)
  • Deliver real-time data updates for both the client-side and the back office (your Clarion Win32 app(s))

All of the approaches mentioned so far have a few things in common:
You need to learn either a platform specific language (or two languages if you develop for iOS and Android) or a specific framework and its tools (Ionic, Cordova, etc.) And you need to write a LOT of code.

That’s why we decided to use Native React. React Native is the next generation of React – a Javascript code library developed by Facebook and Instagram, which was released on Github in 2013.

With React Native, you don’t build a “mobile web app”, an “HTML5 app”, or a “hybrid app”. You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. React Native uses the same platform level UI building blocks as native iOS and Android apps. You just put those building blocks together using JavaScript and React.

Some of the Benefits:
You write JavaScript with React Native but the components/controls are rendered as native platform widgets. Performance is nearly identical to native code apps as long as you understand the nuances of how React Native works. You share the vast majority of your code between both platforms (iOS and Android). You get the benefits of the entire React Native ecosystem. And it looks like in the future we’ll have code sharing with Web apps.

What about the database? If we can generate a great looking, highly performant mobile client, how do we attain real-time data sharing between the Clarion back office applications, and the mobile client apps?

And we have an answer for that with the new Clarion REST server. It’s a full web server that can deliver regular web pages, along with processing JSON requests for data. It delivers real-time data updates for both the client-side and the back office (your Clarion win32 app(s)). It’s 100% Template driven, (so it re-uses your Clarion skills and knowledge) to create a custom REST server without writing any code (based on your Data Dictionary using any of the Clarion database drivers). That means you can securely open up your database to any modern client app that can consume JSON data.

And the Clarion REST server is simple to create using the templates and your Clarion skills. You won’t need intensive training classes or weekly webinars to understand it. Its model is similar (in a way) to the IP Server model, where you create a custom Data dll with templates and any embedded code as needed.

This has become a long post so I’ll end here – there’s a lot to look forward to in Clarion’s future.

Clarion 10 update (May 2017)

Today we released another update for C10. This update fixes some subtle ODBC/SQL driver issues that were reported to us, as well as a number of other issues.  The ODBC driver bugs we fixed required some very specific combinations/conditions, check the readme file for the details.

The H5 technology also continues to improve, you’ll find a number of fixes and new features, as well as performance improvements. We’ve also updated the App Broker to use a more recent version of OpenSSL that offers better stability and security.

If you want to deliver your app to mobile/tablet devices, jump in and take H5 for a test ride, it takes only minutes to see the possibilities. It also works great on the desktop while at the same time completely changing the UIX of your app, and opening up your app to the ever expanding world of Javascript libraries.

Read about all the changes here

Unicode followup

There was a question raised regarding what the new implementation of Unicode support would mean for developers who create Clarion add-on products.  The question was asked:

Does having THREE encoding options mean every 3rd party product will need to include 3 DLL/DLL and 3 LIB/LIB libraries?

And the short answer is NO, no need for that.  Read on for more details.

The three options I showed in a screenshot in this post  new Unicode implementation show the Project Setting encoding options are “ANSI, UTF-8, Unicode”. These project level encoding settings are for the compiler.  The compiler needs to know how to treat string literals.  The following are the rules the compiler uses to determine how to handle string literals:

  • If the source file is encoded as ANSI, strings literals without the U specifier before the apostrophe are taken as is. Unicode string literals with U before the apostrophe are converted by the compiler to Unicode using the codepage value set by the pragma define(codepage=>n).
  • If the source file has UTF-8 or UTF-16 encoding, Unicode string literals
    are taken as is. ANSI string literals without U before the apostrophe
    are converted by the compiler to ANSI using the codepage value set
    by the pragma define (codepage=>n).
  • The Default value for the codepage(when not specified by the pragma define (codepage=>n)) used by the compiler for conversions of ANSI<->Unicode is CP_ACP.

Clarion 11 – new Unicode implementation

The C11 RTL implements new internationalization code all based on the OS locale and codepage settings. All Windows and controls in the new RTL are created and processed using the Unicode variant of Windows API functions. All text drawing also uses Unicode. C11 introduces the new USTRING data type (Unicode analog of CSTRING) and adds official support for the BSTRING data type.

The new internationalization code in the RTL supports conversion between ANSI and Unicode strings on the basis of the system codepage and locale. There are also two new built-in functions TOANSI and TOUNICODE that allow conversions that are not based on the current codepage.

There is a new Project level setting to tell the compiler what encoding to expect:

While Clarion has supported Unicode for a long time you were limited to the system locale setting in the “Regional and Language Options”.  C11 allows as many different charsets as you need.  This test program shows mixing several charsets, and the use of the “U” specifier to tell the compiler that the static string is Unicode text (and the program also uses the TOUNICODE function) –

running the test program produces this –


For more on the technical details read on:
The string stack supports Unicode strings, both ANSI and Unicode strings are handled by the same string stack. If a string expression has the USTRING or BSTRING type
(USTRING or BSTRING variable, Unicode string literal, result of function returning the *BSTRING, *USTRING or USTRING type, or any concatenation if at least one operand is a Unicode expression), then the corresponding element of the string stack is processed as Unicode.

If none of the above applies, then the string is assumed to be an ANSI string (with optimization for numbers). The LEN() function is now a compiler intrinsic. It returns the number of wide chars in the top element’s value, if it is Unicode, or number of ANSI characters, if the top element is ANSI.

* BSTRINGs were designed for use in API functions; they are not suitable for usage as USE variables.

The previous internationlization settings; CLACASE, CLACOLSEQ, CLADIGRAPH are still supported, but are considered as deprecated.

The LOCALE function in C11 supports the following additional parameters:
1) ‘CLALCID=n’ or ‘CLALCID=Windows’ or ‘CLALCID=”ll-cc”‘
Changes the default locale in the Clarion RTL.

If the value is “Windows”, the default Windows user locale is used.
If the parameter has the form “ll-cc”, it can be one of following:
“EN-US” – USA English, default sorting –
“EN-GB” – British English, default sorting –
“ES-ES” – Spain Spanish, default sorting –
“DE-DE” – Germany German, default sorting –
“FR-FR” – France French, default sorting –
“IT-IT” – Italy Italian, default sorting –
“NL-NL” – The Netherland Dutch, default sorting
“RU-RU” – Russia Russian, default sorting –
“ES-MX” – Mexico Spanish, default sorting –
“PT-PT” – Portugal Portuguese, default sorting
“EN-AU” – Australia English, default sorting
“FR-CA” – Canadian French, default sorting
“EN-CA” – Canadian English, default sorting
“EN-ZA” – South Africa English, default sorting
“PT-BR” – Brazilian Portuguese, default sorting
“ES-AR” – Argentina Spanish, default sorting
“JA-JP” – Japan Japanese, default sorting –
“KO-KR” – Korea Korean, default sorting

The locale string settings are case insensitive

2) ‘CLACODEPAGE=n’ or ‘CLACODEPAGE=Windows’ or

Changes the default codepage in the Clarion RTL. If value is Windows, the
current default Windows user codepage is used. If the parameter is a string enclosed in double quotes, it must be one of following: –
– “THAI”
– “UTF7”
– “UTF8”

(case insensitive)

3) ‘CLADOWNAME=s’ or ‘CLADOWNAME=Windows’ Changes the default full names of the days of the week. If the parameter is Windows, the names of days of week from default locale are used. Otherwise the parameter must be a list (enclosed in double quotes) of names to use.

4) ‘CLADOW=s’ or ‘CLADOW=Windows’ Changes default abbreviations of the days of the week. If  the parameter is “Windows”, the abbreviations from default locale are used, Otherwise the parameter must be a list (enclosed in double quotes) of abbreviations to use.

CLALCID and CLACODEPAGE (or SYSTEM{PROP:Locale} and SYSTEM{PROP:Codepage}) are replacements for CLASYSTEMCHARSET, CLACASE, CLACOLSEQ and CLADIGRAPH parameters of the LOCALE/ENV files and for corresponding SYSTEM properties. Old parameters/properties are still supported but locale and codepage are preferable, and all new programs should use them.

Clarion 10 update (Jan 2017)

Today we released an update for C10. This update fixes some SQL driver issues that were reported to us, as well as a couple of regressions introduced in previous builds. A note to the developers who received the internal build: thank you for your help verifying the fixes for the SQL related bugs!

The H5 technology continues to evolve and improve, you’ll find a number of fixes and new features, as well as performance improvements. If you want to deliver your app to mobile/tablet devices, jump in and give it a try. It also works great on the desktop while at the same time completely changing the UIX of your app.

Read about all the changes here

Clarion 10 update (November)

Today we released another update for C10. This build has a change to the VIEW engine; the engine now returns any GPFs that occur inside the View engine as errorcode 90, and the exception details are returned by a call to Fileerror(). It also has a fix for a regression whereby if you had a TIME(0) or TIME(1) column defined in MSSQL Server, and you did a BUFFERed retrieval, the time data would not come back correctly. We’ve also updated the Windows API prototypes to use the corresponding handle names instead of simple data types (LONG,SIGNED,etc.)

There are also numerous new features and changes (and some fixes) for the H5 technology based on feedback from all of you. Expect to see some nice speed improvements.

C10 update is out

Today (Sept 28) we released an update to Clarion 10 (free to all subscribers). This build fixes a problem (regression from a recent build) with the code generated by the compiler to push DECIMAL CONSTANTs with a fractional part to the decimal stack (affected both Decimal and Real data types).

And for those publishing web apps using H5, the App Broker has a fix for handling MEMO fields (> ~2500 chars) where you might get a time-out during an update.

Clarion 10 updated

We just released today (Sept 23) an update for Clarion 10. This build corrects a regression in the ODBC driver layer that affected TABLEs that had defined DECIMAL fields in the FILE structure that were smaller than the definition(s) in the SQL database. It also delivers fixes and new features for the H5 web app layer. You can read all the changes here

Clarion 10 new release is out

We just released (September 13) an update to Clarion 10; build 12327. We’ve updated the H5 template again in response to your feedback, including support for a javascript calendar and a date-time selector. There is more control from the template on the html output, and a lot of new functionality that you requested. The build also has some key fixes for the ODBC driver, and the SQLite driver.

You can read about all the changes here.

Clarion 10 update

We just released (Aug 11) an update to Clarion 10; build 12278. This release is available, free of charge, to all Clarion developers who have an active subscription plan. You can read the list of changes here.

We’ve updated the H5 template again in response to your feedback. There is more control from the template on the output, as well as new functionality, and fixes for reported problems.
I’ve postponed updating the new videos until the template UI settles down, so expect some next week.