Category Archives: Clarion 11


New Status bar implementation (C11)

The new implementation of the Status bar is fully backward compatible. This means that if a program doesn’t use any of the new Status bar/style interfaces, the Status bar is drawn exactly the same as the old implementation. If the interfaces are used, besides the improved visual appearance there are the following changes:

– An empty status bar without zones remains visible and can be used to display
the resize gripper.

– Text from the MSG attribute of controls or menu items is drawn in the
leftmost text zone when the control or menu/item has focus.

Before diving into the details here are a couple screenshots


Big StatusBar

The Status bar implementation exposes a set of 3 interfaces:

1) IStatusZone: gives access to properties of a particular zone;
there are 3 extended interfaces derived from it for Text, Image
and Progress zones – ITextZone, IImageZone and IProgressZone

2) IStatusStyle: represents an instance of the style for the Status bar

3) IStatusBar: represents an instance of the Status bar object

– Supported Properties:
1) PROP:StatusInterface – is used to get a reference to the
WINDOW’s Status bar object

2) PROP:StatusStyle – a SYSTEM property to get the reference to
the default status style object

Both properties are read-only but the returned objects can be modified.

– When the Status bar object is created because of OPENing a
WINDOW with the STATUS attribute, or by setting the PROP:Status
property to a WINDOW without a Status bar, the current default style
is used to set up the bar’s appearance. The Status bar uses its own
copy of the style data. Therefore changes in the default style do not
affect existing status bars automatically. The current bar’s
style can be changed by a call to the IStatusBar.ApplyStyle method.

– Because one instance of the status bar object can be shared by
more than one WINDOW, there is no method to destroy an instance of
the IStatusBar interface. For backward compatibility, the
status bar of a WINDOW can be destroyed by specifying a zero width for
the first zone using the PROP:Status property:

Window {PROP:Status, 1} = 0

– The initial state of the default status Style object mimics the traditional
Status bar’s appearance. The only visual difference are the use of different RGB values
for the colors used to draw the Status bar’s upper border and the zones bevels.

The rest of this post contains the details of the new interfaces.



GetKind – Returns numeric value of zone’s type as they are
listed in the StatusZoneKind ITEMIZE structure


GetWidth – If passed parameter is TRUE, function returns current
actual width of the zone in pixels including all
margins, optional bevel and optional separator.
If passed parameter is FALSE, function returns the
unadjusted width of zone in dialog units.

SetWidth – Changes the unadjusted width of the zone. Rules are the
same as for value passed to the PROP:Status property.
Unadjusted width is given in zone’s dialog units
and does not include zone margins and the optional separator.

If the value is negative, the zone is expandable with minimum
width (in dlu’s) equal to the absolute value of the passed
number. By default, when A zone is created its
unadjusted width is set equal to -1. For text
zones dialog units are determined by the font used
to draw text in that zone. For zones of other kinds,
dialog units are determined by the font from the
Status bar’s style.

HasBevel – Returns TRUE if a bevel is present around the content
part of the zone, and FALSE if no bevel is present.

SetBevel – Modifies zone’s flag controlling the drawing of the
bevel around content area. The passed parameter must be
one of the values listed in the StatusFlagValue ITEMIZE

– STATUSFLAG:OFF – to not draw the bevel
– STATUSFLAG:ON – to draw the bevel
– STATUSFLAG:DEFAULT – drawing of the bevel is
determined by status bar’s style.

Default value is STATUSFLAG:DEFAULT.

HasSeparator – Returns TRUE if separator is drawing at the far edge
of the zone and FALSE if no separator is drawing

SetSeparator – Modifies zone’s flag controlling the drawing of the
separator. Passed parameter must be one of values
listed in the StatusFlagValue ITEMIZE structure:

– STATUSFLAG:OFF – do not draw the separator
– STATUSFLAG:ON – draw the separator
– STATUSFLAG:DEFAULT – drawing of the separator is
determined by the Status bar’s style.
Default value is STATUSFLAG:DEFAULT.

If the last zone has the separator flag equal to STATUSFLAG:DEFAULT, the
separator is not drawn regardless of the style settings.


GetText – Returns the current text of the zone. The returned value can be
passed to the ToString function to convert it to a STRING type.

SetText – Changes the text displayed in the zone. Default value is
an empty string.

GetAlignment – Returns the numeric value of text alignment as they are
listed in the StatusAlignValue ITEMIZE structure. The

! Alignment of text in text zones


SetAlignment – Changes the text alignment in the zone content area,

GetIndent – Returns the value of text indentation in pixels relative to
the base point determined by current alignment.

SetIndent – Changes text indent value to the passed value, countied in
pixels. Default value is 0.

GetFont – Returns an instance of the IFontProperties interface
allowing to modify parameters of the font used to
draw text in the zone. A NULL result means that the zone is
using the font specified by Status bar’s style.

SetFont – Changes the font used to draw text in the zone.
Default value is NULL, i.e. usage of the font from the
Status bar’s style.

*** Notes:

The IFontDescription interface has no public methods to clone and destroy
instances. ITextZone.SetFont automatically releases the previous zone’s
font (unless it is NULL), clones the passed font (unless it is NULL) and
set it to zone. The expected flow of work with a zone’s font is as

ZoneFont &= BarStyle.GetFont() ! Get the font from style
Zone.SetFont (ZoneFont) ! Set the clone of font to zone
ZoneFont &= Zone.GetFont() ! Get the reference to cloned font
… modify font …
Zone.FontChanged() ! Notify zone that font changed

GetTextColor – Returns the color used to draw text in the zone. If the zone
has its own font, the returned value is equal to
result of call to IFontProperties.FontColor() for this
font. If the zone is using the default font from the bar’s
style, the text color can be changed separately. In this
case, GetTextColor() returns that color value.

SetTextColor – Changes color of==used for drawing text. If the zone has its own
font, this function has the same effect as a call to the
font’s IFontProperties.FontColor(newcolor) method. If the
zone is using the default font from the bar’s style, this
function can be used to change text color in the zone
while retaining all other characteristics of the default

FontChanged – This method must be called to notify the zone that its font has
been changed by calls to methods of the IFontProperties
interface returned by the GetFont function.


GetImage – Returns the name of the image drawn in the zone. Returned
value can be passed to the ToString function to convert
it to STRING type.

SetImage – Sets/changes the image displayed in the zone. Default value is
NULL which means that zone remains blank.

*** Notes:

If the width of zone is greater than the width of the image, the image is drawn
left aligned in the zone content rectangle (right-aligned in case of
right-to-left window layout). If width of the zone is less or equal to the width of
the image, the image is drawn centered in the zone content rectangle.

GetDrawMode – Returns the numeric value of the image drawing mode
as they are listed in the StatusImageMode ITEMIZE

! Modes of drawing images in image zones


SetDrawMode – Changes the mode to draw zone image. Parameter must be
one of values listed in the StatusImageMode ITEMIZE
structure. Default value is STATUSIMAGE:NORMAL.


GetValue – Returns the current progress value.

SetValue – Changes the current progress value.

GetMin – Returns the lower bound for progress value.

GetMax – Returns the upper bound for progress value.

SetRange – Changes the lower and upper bounds for the progress value.
Default range is 0..100

GetColor – Returns the color used to draw the progress bar.

SetColor – Changes the color to draw the progress bar.

*** Notes:

If the progress zone has a bevel, the bevel is used as the frame for
the progress bar. If the zone has no bevel, additional lines are drawn to
show the unfilled part of the progress bar.


Clone – Returns a cloned copy of the style object.

Destroy – Destroys the style object. The Destroy method must
be called for all style objects returned from calls
to IStatusStyle.Clone methods.

CreateBar – Creates the status bar object for the passed WINDOW
using the style determining by SELF. The previous
WINDOW’s status bar object is disposed. It is not
recommended to use this function for the active MDI
child window. Created status bar has no zones and
is frozen.

Apply – Copies information from one style object to another.
Can be used for “atomic” changing of the system
default status style.

GetMetric – Returns the value for the given style metric. Parameter
must be one of values listed in the StatusMetric
ITEMIZE structure.

Supported metrics are:
STATUS:HMARGIN – margin from status bar edge to first
zone and, if no resize gripper is drawn, from
the last zone to the status bar edge. Default value
is 4.

STATUS:ZONEHMARGIN – Horizontal margins around the zone content
rectangle. Default value is 4.

STATUS:ZONEVMARGIN – Vertical margins above and below the zone
content rectangle. Default value is 2.

STATUS:TEXTHMARGIN – Horizontal margins around the
text bounding rectangle in text zones. Default
value is 2.

STATUS:TEXTVMARGIN – Vertical margins above and below the text
bounding rectangle in text zones. Default value
is 0.

STATUS:TEXTINDENT – indentation of text relatively the
base point (determined by text alignment) in the
text bounding rectangle. Default value is 0.

STATUS:SEPMARGIN – margins above and below the zones’
separator line. Default value is 2.

***Notes: All returned values are in pixels.

SetMetric – Changes the given style metric. The first parameter must
be one of values listed in the StatusMetric ITEMIZE

GetHeight – Returns the height in pixels of the status bar determined
by the style. If the parameter value is FALSE, the function
returns the value set by last call to the SetHeight method.
If parameter is TRUE, function returns adjusted height
value. Adjusted height is maximum of GetHeight(FALSE)
and height calculated from style’s font and metrics.

SetHeight – Changes the unadjusted height for styled status bars.
Passed value must be in pixels. Default value is 0,
i.e. the adjusted height is determined by the font and

BkgndBrush – Returns the instance of the IBrush interface used to
draw the Status bar’s background. If IBrush.Type is
CWBrush_Null (default), the background is painted
using the COLOR:BTNFACE color.

GetFont – Returns the instance of the IFontProperties interface
used as the default font for Text zones.

SetFont – Sets/changes the style’s default font. If the passed parameter is NULL
(default), the font specified by SYSTEM properties is used.

GetTextColor – Returns the default color used to draw text in Text

SetTextColor – Changes the default color used to draw text in Text
zones. If the passed value is COLOR:None, the color returned
by SYSTEM{PROP:FontColor + PROP:StatusFont} is used.

GetProgressColor – Returns the default color used to draw Progress bars in
progress zones.

SetProgressColor – Changes the color used to draw Progress bars in
progress zones.

GetSeparatorColor – Returns the color used to draw flat separator lines.

SetSeparatorColor – Sets/changes the color used to draw flat separator lines.

HasZoneBevel – Returns the default value of the flag to draw bevel around
the content rectangle for zones of a given kind.

SetZoneBevel – Changes default value of the flag to draw the bevel around
content rectangle for zones of the kind given by the first
parameter. Default value is TRUE for text zones and
FALSE for image and progress zones.

GetFlag – Returns value of the style flag corresponding to
passed parameter. Parameter must be one of values
listed in the StausStyleFlag ITEMIZE structure:

STATUS:THEMED – if TRUE, and themes are available for
the program, some metrics and visual aspects are
determined by the visual theme rather than by values
set in the style. If the flag is FALSE, style does not
use the visual theme.

STATUS:SEPARATOR – if TRUE, the separator line is
drawn after every zone except the last one by default.

If the flag is FALSE (default), separators are not
drawn unless this setting is overridden in a
particular zone.

STATUS:GRIPPER – If TRUE, the resize gripper is drawn
in the lower-far corner of status bars owned by resizable
not-maximized WINDOWs. If flag is FALSE (default),
the gripper is not drawn.

STATUS:BORDER3D – If TRUE, the status bar’s upper edge
is drawn using a bevel. If the flag is FALSE, a flat
border is drawn. The flag only affects not-themed
status bars using solid colors to paint the bar’s
background. The flat border is drawn in all other

STATUS:SEPARATOR3D – If TRUE, separator lines are drawn
using a bevel. If the flag is FALSE, the separator line
is drawn flat. Flag is ignored for themed status

SetFlag – Changes value of the style flag corresponding to passed
first parameter. This parameter must have one of values
listed in the StatusStyleFlag ITEMIZE structure.


ApplyStyle – Applies parameters of the passed style to the status bar.

NumZones – Returns the number of zones in the status bar.

GetZone – Returns the reference to object implementing the zone
with passed index. Index value is 1-based. If passed
index is 0 or greater than number of zones, a NULL
reference is returned.

AddZone – Creates the object implementing the zone of given kind
and inserts it at position specified by first parameter.
If position parameter is out of range 1..,
the created zone is appending to the end of list of zones.
The position value is 1-based.

DeleteZone – Destroys the number of zones equal to the second parameter
starting from the position given by the first parameter. By default,
the only zone is creating. If second parameter is 0,
all zones since passed position are destroyed.

*** Notes:

DeleteZone can be used to delete all zones from the status bar. This leaves
an empty status bar.

Freeze – Freezes the status bar to avoid multiple redrawings on
volume changes to zones.

Unfreeze – Unfreezes previously frozen status bar. More than one
level of freezing is possible, therefore the number of calls
to Unfreeze must be equal to number of calls
to Freeze.

SetClickCallback – Sets a callback function that is invoked if the mouse is clicked or
double clicked within content rectangle of any zone. The
1-based index of clicked zone is passed to the callback
function as a parameter. The KEYCODE() function can be used
to determine which mouse button has been clicked.

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

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.