Monthly Archives: May 2011

Clarion.Net update

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.