An update for Clarion.Net is out today.  It has a good number of fixes and delivers the previously described feature that automatically exposes Procedures you select so that they are visible to Clarion Win32 Apps.  I wrote about this a while ago, so I’ll refresh you on it (this is straight from the Help file):

1) In the Clarion# Program’s GLOBAL MAP, add both the NAME and PUBLIC attributes to the PROCEDURE prototype

For example in your Clarion# global Map:

MAP

! Procedures exposed for Win32 access must have both the NAME and PUBLIC attributes
SayHello                     PROCEDURE(),NAME(‘SayHello’),PUBLIC
SayTheName            PROCEDURE(string theName),NAME(‘SayTheName’),PUBLIC

END

2) On the Clarion# Project properties dialog, turn on the checkbox: Export Global named procedures and create Clarion Win32 LIB file

This step causes a .LIB file to be created, its location is set according to your RED file, or you can specify the output path in the Project

3) Copy both the .LIB and the Clarion# DLL to your Win32 project folder.  You also must copy any assemblies (DLLs) that your Clarion# DLL references, for the minimum you need:

SoftVelocity.Clarion.Runtime.Procedures.dll
SoftVelocity.Clarion.FileIO.dll
SoftVelocity.Clarion.Runtime.Classes.dll
ClarionDrv.dll

4) In the Clarion Win32 program prototype the Procedure(s), and add the PASCAL and DLL attributes. If you need to pass a string value by address also add the RAW attribute.

MAP

MODULE(‘ManagedDLL.dll’)

! Calling Clarion# Procedures, you must use the PASCAL Attribute and set DLL(true)
SayHello            PROCEDURE(),NAME(‘SayHello’),PASCAL,DLL(TRUE)
SayTheName   PROCEDURE(*cstring theName),NAME(‘SayTheName’),PASCAL,RAW,DLL(TRUE)

END

END

In the initial implementation (its already changed internally),  you might run into a “gotcha” when you get to step 2.  In order to expose the Procedures for use in a Win32 program the binary Clarion# DLL file has to be disassembled back to IL code, the IL code is then modified, and then the IL code has to be assembled back to a binary (PE format) file.  To do this there are two programs from the .Net SDK that have to be found; Ilasm and Ildasm.  In the current implementation the location for those files is stored in an external .config file, and if they are not found (Ilasm and Ildasm), you’ll get an error message telling you to edit the path stored in Dllexport.exe.config.  In the next release we’ll have an improved implementation that finds these automatically on all OS’s (32 or 64 bit).

You’ll find an easy to understand example showing how this works in the .SamplesWin32toDotNet folder.

The AppGen for Clarion.Net is making steady progress (despite a few wild rumors to the contrary).  It’s a given that the progress is much slower than we would like, and in moment I’ll explain why that is the case. The core of Clarion.Net just like Clarion Win32, is not the AppGen, but is the Clarion language and Clarion runtime function library.  For those who are willing and capable of writing their own code (as opposed to generating it), Clarion.Net has long been both productive and complete. Let’s take stock on what we have now.

Well first and foremost we have the Clarion language, extended to be able to take full advantage of the .Net Framework while maintaining compatibility with Clarion syntax and language features. Let’s not underestimate the importance of this. I know there are those developers who claim they don’t care what the language is, but they are the minority. For most of us, the language we read and write to build our applications has great significance.

Next we have the Clarion Runtime, every function we have in Clarion Win32 we also have in Clarion.Net. The entire runtime has been ported to 100% verifiable .Net code with the exception being Window structures and the corresponding Accept loop and its related functions. So we lost Window structures, but did we gain anything in the trade? Yes we did, we gained the ability to seamlessly work with any add-on UI component library available. As you know Window structures are constrained to the core set of controls that we have had since the introduction of the Clarion for Windows product. Not so for Clarion.Net, the world of add-on controls is now wide open. And when we talk about the Clarion runtime let’s not overlook that this support encompasses the Clarion Driver technology. Driver support is bread and butter for most of us.

Is there anything else? Can we ignore what might well be the most important reason for some? Clarion.Net enables you to use you existing Clarion knowledge to build and deploy .Net applications for all of the platforms supported by .Net (Desktop, Web, and Mobile). Of course you could pick up a new language, and in a few years be a master of it. But your knowledge of the Clarion language shouldn’t be taken lightly, it’s a valuable asset.

Is that all? You have access to the entire.NET Framework and all of its classes and methods, including XML Web service classes. You have painless interoperation with both COM and native code Libraries. Clarion.Net programs and code can be integrated seamlessly with any other .Net languages; inheriting from classes created in other languages, invoking and being invoked by methods written in other languages, in other words you can use any library written in any .Net language, the same as if it were written in Clarion.Net. And the reverse is true.

So that’s what we have now, but what we’re missing is the code generation that separates Clarion from all competitors. As you may know the template language used in the new AppGen.Net is a complete departure from the syntax used by the templates in our Win32 Application Generator.  In place of the Clarion template language we use an extended set of T4 template directives. The extended set of T4 template directives include equivalents for our #PROCEDURE, #CODE, #GROUP, #CONTROL, #EMBED and #AT and #EXTENSION directives as found in our Win32 template system. And there is the root cause of the delay. The T4 engine has many advantages for generation of .Net code – but it’s primarily capability by design is for generation of individual classes and code snippets. The base premise of Clarion code generation is one of round-trip code generation, embedded code within the generated code block, generation of entire applications, and at the core, an Application tree that represents the structure and relationships of procedures within the application.  We very badly underestimated the complexities of imposing this required functionality onto the T4 engine, and it cost many more man-hours than we projected in our most generous estimations. We apologize for that, as we know a lot of Clarion users are purely AppGen developers, and are not going to be productive without the code generation functionality. But on the plus side, we now have the prerequisite functionality working, almost completely. And our stated plan to make the templates available on a public subversion repository so that users have instant access to updates and fixes, and have the ability to contribute new features and fixes (or even new templates and template sets) remains central to our plans (both for .Net and Win32).

The long-term goals remain unchanged; to create a code generation environment that opens the doors to WinForms, WebForms. Compact Forms, WPF and Silverlight. And in fact beyond those platforms, the new AppGen will open a path to Android and iOS. In order to get it into your hands faster, the initial templates will scale back on some of the optional features like the option to generate test cases (nUnit) for aspects of the APP. That can added later, by us, or by the community.

In the interim before the release of the AppGen for .Net we’ll be releasing an update to Clarion.Net that has a number of fixes and delivers the new technology that allows you to easily expose Clarion.Net methods to your Win32 Clarion applications.