Deliver line of business software on time, every time

9.1 – beta 7 on its way out

The new beta release is on its way out.  You can read all that’s new here.  We’ll take feedback until Wednesday (April 16) and if all is good we’ll offer a pre-release to all developers with  current subscriptions.  It looks like we have all significant issues resolved after adding the touch input support – and we’re pretty happy with the results for Clarion developers being able to offer full Win 8.1 desktop touch input support without having to change a single line of code.  Of course there is complete low-level support for touch input with accompanying class wrappers so you can make your app do anything that Win 8.1 supports. There are just a few things that we expect to add to the templates that enhance the touch experience — those will come in the next release later this week.

9.1 – beta 6 released

The 6th beta is out today (March 27). There are ~50 fix/changes/new features added to this release. We expect that next week we’ll make a final pre-release available to all users. You can view the complete list here.
Some of the new features in this release -

  • New WindowManager method ModalEvent added that can be used to test if the current event is modal or not
  • The ODBC driver now supports generating JOIN structures where the the column names in the ON clause of the outer join are in the same order as their respective table names in the OUTER JOIN clause
  • The ODBC interface to TPS now supports LEFT OUTER JOIN clauses on the left hand as well as the right hand side of a join. If a join is on the left hand side, then it must be enclosed in brackets
  • a new XMLWriter class to easily write new XML files

9.1 – beta 5 is out

Yesterday (March 13) we released an updated beta version.  We are getting close to a general release and we’ll know better after the beta testers have had a few days to work with this release.

On the topic of conversions between LONG and TIME data types we introduced two new Pragmas. You can control how the conversions between a TIME field and a LONG are handled using these PRAGMA settings:

PRAGMA (‘define(time0=>off)’) or PRAGMA (‘define(time0=>on)’)

PRAGMA (‘define(sqltime0=>off)’) or PRAGMA (‘define(sqltime0=>on)’)

Summary of behavior when these pragmas are set on/off:

PRAGMA (‘define(time0=>off)’)

This is the default value. TIME(0) is converted to 1 (TIME:MIDNIGHT), i.e. mid-night to mid-night.

PRAGMA (‘define(time0=>on)’)

The compiler generates code to convert TIME(0) to 0 (TIME:NOTIME).

PRAGMA (‘define(sqltime0=>off)’)

This is the default value. The compiler does nothing additional for fields of SQL tables having the TIME data type.

PRAGMA (‘define(sqltime0=>on)’)

If the TIME value to convert is a field of a FILE, the compiler generates a call to the NULL function. If the result from the NULL() function is TRUE (field has a NULL value), the TIME field is converted to 0 (TIME:NOTIME) value. Otherwise, conversion is controlled by the define(time0) pragma.

It is easiest to set the PRAGMA to the desired value at the Project level (Project Properties) But PRAGMA directives can be set before any line in your code where TIME value is being used in an expression converting TIME to LONG).

Related; All SQL drivers have been updated so that a call to NULL(datefield) or NULL(timefield) will return TRUE if they are part of a DATE/TIME Group, and the corresponding column on the server is NULL.

9.1 – beta 4 is out

We released 9.1 beta 4 last Friday (Feb 14).  The news on the 9.1 release has been focused on Touch support and Registration-free COM support, but there is a LOT more than that in this release.  Check the readme here for the complete list of fixes/changes and new features. We’ve expanded the beta test group to ~100 developers – if you’re a Clarion developer who is interested in working with the beta version, and have the time and patience to work with beta software… we’d be glad to add you the group – send an email to support to request access.

9.1 – 2nd beta is released

We just released the 2nd beta of Clarion 9.1.  You can check the fixes/changes/features since the release of 9.0 here

9.1 and Reg-Free COM

As previously posted 9.1 introduces support for registration-free COM activation.  That simply means that you can deploy your App that uses any COM controls without having to install and “register” the COM control. You simply include the binaries for the COM controls and deploy it with two manifest files; one manifest for your App that specifies the “dependency”, like this example:


After talking about this on Wednesday on ClarionLive we went and added this support to the templates.  It is as simple as this example:


Now the only thing left is for you to create the manifest for your COM control.  There are various tools out there like “Make My Manifest” (link) and “Unattended Make My Manifest” (link), as well as several others, which handle the manifest creation for registration-free COM.

Clarion 9.1

The next Clarion release (9.1) has over a dozen new features, and many bug fixes and changes to improve the RTL and IDE, but two new features stand out above the others.  That is the support of Touch input and  the support for Registration-free activation of COM objects from side-by-side assemblies.

The Touch support is automatic and transparent, no code changes needed — just a rebuild of your app and you have it.  But you also have the option to use an interface to take full control of all the touch events and handle them as you see fit.  We have a few good examples that will show you exactly how to do that.

The Reg-free COM support is also automatic, and likewise requires no change to your code. If the OCX ProgID isn’t found in the OS registry then the RTL looks for a local manifest.  The declaration of the interfaces in the OCX can be placed in either the program’s manifest or in a separate manifest. In the latter case, the program manifest must contain the <dependency>
block with assembly name equal to name of the OCX’s manifest without the “.manifest” extension (this the preferable way).

Tomorrow we’ll be expanding the group of Clarion 9.1 alpha testers, and our goal is to get 9.1 to all 3rd party vendors by the end of the week.  If all goes well within another ~week it’ll move to a general release.



H5 Builder

At CIDC in September we showed a quick demo of an H5 enabled app.  For the details on what the H5 product is all about you can read this;

At the conference I talked about our plans for H5:

H5 will be included with a future C9.x EE.  H5 will be our first Clarion Community open source project.  We’ll be posting the templates and classes onto GitHub so that Clarion developers from around the world can hack, enhance, branch, and generally share their ideas and expertise (working along side our core dev team).  At the conference quite a few of the Clarion devs present indicated they are looking forward to getting involved with the project, and I think there are many more who weren’t at the conference who will join in.

Currently we are refactoring the templates/classes to move each control into separate file(s).  This is a necessary first step to ensure its easy to work on files and get them checked back into the common repository while minimizing conflicting changes.  We expect to open the project on GitHub in approximately 2 weeks.

Template for creating a CLASS in an .App

At the CIDC conference we showed a template (that is already included with C9) for easily creating CLASSes within your APP.
The Help doesn’t yet cover it, (but will in the next update) and it’s very simple to use without any docs. Here are a few screenshots to get you going;

start by inserting a new procedure and then select “Source Class”

if you press the Actions button, you have the option to declare the module as a generic MEMBER() so you can share the class between Apps as needed.  (this option was actually added during the devcon based on feedback during the presentation)


the embed points are pretty much self-explanatory



You may have noticed the other new template Procedure “Generated UserControl Class”. As the name implies that template creates a ‘user control’ which is comprised of a Window and all the controls on it.  We’ll post separately about that one.

REPORTs in the new RTL

Clarion uses Windows metafiles to generate reports since the very first version of Clarion for Windows. A metafile is a sequence of records containing a list of GDI functions and parameters. Metafiles are created in memory and can be written to disk files. The RTL also uses metafiles to handle direct drawing operations like ARC() or PIE() in both WINDOWs and REPORTs. A metafile is a simple way to store drawing operations but there are several issues:

  1. Windows metafiles do not support all GDI functions used for drawing. For example, images with semi-transparent parts cannot be stored in Windows metafiles.
  2. Reports are sequences of bands and bands consist of controls and can be nested. Multiple drawing operations can be required to draw individual controls. For example, multiple lines and multiple strings must be drawn for LIST controls. Reports are best represented as a tree structure, and metafiles with their linear organization are not an easy/adequate way to represent them.
  3. The RTL must carefully track images, pens and fonts used in metafiles to avoid leaking of resources.

Problem (1) can be solved by use of Enhanced metafiles (EMF) instead of Windows metafiles (WMF). But other problems exist for both types of metafiles. The RTL must enumerate metafile records every time some delayed action needs to be executed, for example when processing widow/orphan settings to find end of page. The RTL inserts additional records into metafiles to mark logically related records and assist in enumeration and parsing both during report generation and during conversion metafiles to text/PDF/XML/HTML format.


The new RTL won’t use metafiles for direct drawing operations or during report generation. Instead it will produce a dynamic tree structure matching the Report with a sequence of drawing operations. Every tree node is a class instance derived from the MetaNode class:
MetaNode       CLASS,TYPE
Next             &MetaNode
Bounds           LIKE(RECT)
Flags            ULONG
Custom1          LONG
Custom2          LONG
Draw             PROCEDURE (LONG context),VIRTUAL

ContainerNode  CLASS(MetaNode),TYPE
Nested           &MetaNode

PageNode       CLASS(ContainerNode),TYPE
Print            PROCEDURE (HDC, ULONG skipmask)

IndirectNode   CLASS(MetaNode),TYPE
Actual           &ContainerNode

There are 3 categories of nodes:

  1. Nodes with information to execute a direct draw operation or to draw a control. A Nodes’ classes have fields for all values required to perform both drawing and post-processing: fonts, colors, pen style and width, value of the EXTEND attribute, etc.
  2. Container nodes used for referencing a list of nested nodes.
  3. Indirect nodes referencing some Container node.

The container node class for a report page has a function to start drawing or printing. The call to this function initiates iteration of the page sub-tree and calls the Draw method for every node. This approach provides a very easy method to get a page in any required form:

  • If the HDC parameter is a handle to a screen device context (DC), the page contents are drawn on screen.
  • If the HDC parameter is a handle to a printer DC, the page contents are sent to the corresponding printer.
  • If the HDC parameter is a handle to an Enhanced metafile DC, an .EMF file with the page’s image is generated.
  • If the HDC parameter is a handle to a Windows metafile DC, a .WMF file with the page’s image is generated.


The skipmask parameter of PageNode.Print function is used to filter which nodes to print/draw. If the value of the expression

BAND (node.Flags, skipmask)

is not 0, the node (and all nested nodes for container) are not drawn.  Filtering nodes can be used in multiple ways, for example to exclude some pages from printing, or to show the document form at preview time but not print it without needing to re-generate the report. The program can set its own flags in high WORD of the node’s Flags field (low WORD is reserved for Clarion internal use). The program also can use node’s Custom1 and Custom2 fields to store any useful data associated with that node.

Position of nodes corresponding to bands (FORM, HEADER, FOOTER, DETAIL, BREAK) is calculated relative to the page origin. Position of controls is calculated relative to the origin of the band they belong to. This allows us to have “references to containers” implemented by indirect nodes. Upon drawing/printing an indirect node the RTL uses its position, flags, custom data and a list of nested nodes of the container it points to. Indirect nodes are used internally to handle the FORM band, which is shared by all report pages. But a program can use them in other ways, for example to merge several short reports to print them on the same page, or to print a number of copies of specific pages.



The new internal organization for Reports retains complete backward compatibility with the current and prior versions of the RTL because WMF files can be easily generated for every page.  But it opens the door to numerous potential enhancements:

  1. Faster report generation by eliminating the need for repeated re-scanning of metafiles to merge them or to find the point of a page break.
  2. Easier conversion of reports to formats other than WMF and EMF by elimination of the need to parse the WMF file to reconstruct the structure of the report in another format.
  3. Easier after-generation modification of reports, for example placing the correct total number of pages to “Page n of N” text.
  4. The possibility to have report pages with multi-layered contents and then selecting the desired layers at preview time.

Post Navigation