Category Archives: Clarion 11

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.

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
‘CLACODEPAGE=”cp”‘

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: –
– “WESTERN”
– “CENTRALEUROPEAN”
– “CYRILLIC”
– “GREEK”
– “TURKISH”
– “BALTIC”
– “HEBREW”
– “ARABIC”
– “KOREAN_JOHAB”
– KOREAN_HANGUL”
– “SHIFT_JIS”
– “SIMPLIFIED_CHINESE”
– “TRADITIONAL_CHINESE”
– “THAI”
– “VIETNAMESE”
– “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.