Clarion.NET First Look

by Dave Harms

Published 2007-11-20    Printer-friendly version

The first Clarion.NET beta was released to subscription program participants on Saturday, Nov 17, 2007. Mark that on your calendar, because it's the beginning of a new era.

First, a few cautions about the beta. One, it's a beta, so you know some stuff won't work the way it should. Two, there's no AppGen yet, so you can't develop massive Clarion.NET applications (although there is a C6 wizard that will generate a basic app for you from your dictionary). More on the template later. And three, most importantly, is that these are early days; not only may there be unintentional errors in this document, but some things may change, and may even change wildly, between now and final release (in particular the wizard-generated source code).

Okay, with the disclaimers out of the way, let me just say that this is one rockin' product.

Like a lot of Clarion developers, I'd been waiting for this baby for a long, long time. And like many other folks I'd done some .NET programming in Visual Studio, and even a little in SharpDevelop. So I thought I had a pretty good idea of what to expect in Clarion.NET. And yet...

It's one thing to anticipate that Clarion will do .NET. It's another thing to open up the new IDE and see that you can use it to create:

• Windows Forms (WinForms) applications
• ASP.NET applications (Enterprise Edition only)
• Compact framework applications (Enterprise Edition only)
• C# applications
• VB.NET applications

I did mention that the AppGen isn't ready yet, right? And there may not even be C# or VB.NET templates any time soon, and okay, those languages are courtesy of the SharpDevelop IDE code base so let's not get all het up about it. But still.

Think about it.

We're talking Windows application development using an industry standard platform. ASP.NET web development with IIS. Mobile applications. Mixing and matching with other .NET languages. Full access to the many benefits of the .NET platform. A wild selection of add-on programming tools (profilers, code obfuscators, unit testers, etc.), not to mention instant compatibility with a massive number of controls and libraries (and for many existing Clarion third party vendors, a truly huge new market...).

I generally prefer my prose deathless rather than breathless, so before someone accuses me of channeling Russ Eggen, I'll try to curb my enthusiasm and get down to the nitty gritty.

The Clarion.NET IDE

First, as noted in the Clarion.NET FAQ, the name Clarion.NET refers to the IDE, and Clarion# is the .NET version of the Clarion language. If you've already seen the C7 IDE then you'll find Clarion.NET familiar (see Figure 1); both products use the same IDE, which is in part based on the SharpDevelop IDE (for which SV obtained a commercial code license).

Figure 1. The Clarion.NET IDE, default layout (view full size image)

I won't go over the IDE in detail - if you want to see more screen shots I suggest you review the C7 alpha/beta articles. There are, however, a few significant additions in the .NET version.

.NET project types

As I indicated earlier, the beta release includes hand code support for all three Clarion.NET development targets: WinForms, WebForms (ASP.NET) and the Compact Framework (mobile devices).

Figure 2 shows the available project defaults for WinForms desktop apps.

Figure 2. WinForms defaults

WinForms defaults include:

• Class Library - create just a class library with no EXE entry point. This is a bit like creating a WinAPI DLL.
• Console Application - create an application that writes to a command (i.e. DOS) window. You can still interact with a console application but only via the keyboard.
• Windows User Control Library - create your own custom window control derived from System.Windows.Forms.UserControl.
• Windows Application - the starting point for most application development; creates an executable .NET application.

Figure 3 shows the available project defaults for ASP.NET (WebForms) desktop apps.

Figure 3. WebForms defaults

There are two ASP.NET options, a web application and a web service. There are already-created sample apps (see below) but you might as well create your own as this gives you the option of setting up the IIS virtual root. I couldn't get that feature to work on my machine but I suspect that's because I'd munged up my IIS configuration during testing.

The ASP.NET app provides a basic setup for an ASP.NET application, including a default.aspx file and a global.asax file, both with matching code-behind Clarion files. There is also a brief style sheet. The web app simply displays a "Hello from Clarion" page.

The services app provides a similarly basic framework for web services. The .NET library code supports both HTTP and SOAP protocols. The service generates a test web page which gives you helpful information on the XML file formats to use when calling using the SOAP 1.1 and 1.2 protocols. There are three simple functions included: add two numbers; say "Hello"; and say "Hello name" where you pass in the name. You can test these functions with the supplied page using the HTTP protocol, which returns the result in a simple XML page, like this:

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://tempuri.org/">Hello Dave</string>

You'll need a SOAP client to test the SOAP 1.1 and 1.2 protocols. There's no such client included with Clarion.NET, but as you'd expect there's support for such a beast in the .NET framework and I found a C# example which you may want to try.

Update: SoftVelocity's Deigo Borojovich showed me how to set up a Web Reference, which automatically creates the code to consume an HTTP web service. I'm have more on this in another article shortly.

Figure 4 shows the available project defaults for Compact Framework applications.

Figure 4. Compact Framework defaults

There are two CF defaults in the beta: Windows CE and PocketPC. At this point there doesn't seem to be any difference in the code created for these two defaults, but perhaps that will change in time.

Sample projects

Clarion.NET ships with a number of sample projects. These include:

• ADONetEx - console app that attaches to any ADO.NET data source.
• BlobBinaryToImage - read a TopSpeed BLOB image and display it in a .NET PictureBox control.
• CFDemo - a Compact Framework app using XML files for data storage.
• DataBind-Files-Records - databinding example using a TopSpeed file and the .NET 2.0 BindingSource and BindingNavigator controls. Also demonstrates binding a textbox control to a field in a record structure.
• DataBind-Queue - demonstrates binding a queue to a .NET datagrid control, among other things.
• DockingWindows - demonstrates docking the WeinfenLuo.WinFormsUI.Docking DLL. Also shows how to use the Clarion.NET IDE's docking features (movable MDI windows) in your own programs.
• DragandDropImage - drag and drop an image.
• DragandDropText - drag and drop text between list boxes.
• ForEachQueue - a console app showing how to use FOREACH with a queue.
• GlassButtons - demo of SV's glass button controls.
• ListControlTotallingTree - manipulate column headers and run dynamic totals on a list.
• MDI-Dgv - demo of TYPEd files, where each instance of the file has its own data buffer.
• MixedLanguages - calling C# from Clarion# and vice versa, using two projects in one solution.
• MyFirstWebService - launch a basic web service.
• MyFirstWebSite - a simple WebForms/ASP.NET application.
• NetRemoting - demo of .NET's inter-application communication capability.
• People - the People example for .NET.
• ScreenCapture - using the System.Drawing classes to capture the screen.

The sample projects alone provide many points for future study, and do a good job of illustrating the breadth of programming options available in Clarion.NET. I'll cover some of these samples in future articles.

WinForms

Drag yourself away from web apps and mobile apps for a moment. I mentioned earlier that Clarion.NET comes with a Clarion 6 wizard that lets you generate a WinForms app from a dictionary of your choosing. You won't get a complicated application, just a bunch of browse-form pairs, and you can't edit them in any AppGen, but these applications can be compiled in Clarion.NET and do work. This is an interim measure until AppGen arrives, and it mainly serves as a way to provide developers with Clarion# code they can study.

Clarion is originally a procedural language, with object-oriented extensions. .NET, however, is only an object-oriented platform. But Clarion# retains its hybrid nature, so you can still write procedural code if you want - your procedures are converted to class methods under the hood.

The generated code for the main module demonstrates this hybrid nature, and looks for the most part like the code at the start of any current Clarion program:

DISCLAIMER: The following wizard-generated code is purely for illustration purposes. It is not necessarily indicative of the code that will be generated by the Clarion# template chain. In particular I would not expect to see legacy-style utility procedures declared in the MAP.

PROGRAM

 NAMESPACE('PEOPLEApp')
 USING('System')
 USING('System.Drawing')
 USING('System.Windows.Forms')

!!! <summary>
!!! Description of RequestType ENUM
!!! </summary>
RequestType ENUM
None          ITEM(0)
InsertRecord  ITEM(1)!  Add a record to table
ChangeRecord  ITEM(2)!  Change the current record
DeleteRecord  ITEM(3)!  Delete the current record
SelectRecord  ITEM(4)!  Select the current record
ProcessRecord ITEM(5)!  Process the current record
ViewRecord    ITEM(6)!  View the current record
SaveRecord    ITEM(7)!  Save the current record
            END

!!! <summary>
!!! Description of ResponseType ENUM
!!! </summary>
ResponseType ENUM
    None             ! 0
    RequestCompleted ! 1 Update Completed
    RequestCancelled ! 2 Update Aborted
             END

 MAP
   AutoIncColumn(System.Data.DataRow NewRow, |
     System.Data.DataTable AppDataTable, STRING FieldName)
   StopValidation(System.Windows.Forms.Control ctrlParent)
   CheckOpen(FILE pFile,bool OverrideCreate=true,|
     BYTE OverrideOpenMode=66),System.Int32
 END

GUIDStr                     CLASTRING(16),PUBLIC


!Region Files declaration
people       FILE,DRIVER('TOPSPEED'),CREATE,BINDABLE,TYPE
KeyId          KEY(Id),NOCASE,OPT,PRIMARY
KeyLastName    KEY(LastName),DUP,NOCASE
Record         RECORD
Id               System.Int32
FirstName        CLASTRING(30)
LastName         CLASTRING(30)
Gender           CLASTRING(1)
               END
             END                       
!endregion

 CODE
 !These functions are used to enable XP 
 !visual styles for application.
 Application.EnableVisualStyles()
 Application.Run(NEW MainForm())

There are a few statements right at the top that may look unfamiliar. The NAMESPACE directive indicates that anything newly declared in this file will automatically have its label prefixed with PEOPLEApp, followed by a period. That means, for instance, that RequestType is really PEOPLEApp.RequestType. Namespaces are how .NET avoids name collisions. You can have different classes called, say, String, provided they are declared in different namespaces.

Writing fully qualified class names, which means the namespace and the name, can get tiresome especially when you have nested namespaces such as System.Windows.Forms. The USING statements allow you to use a sort of shorthand - the compiler will automatically try the namespaces listed in USING statements when its attempting to resolve a label in your code.

You still have a PROGRAM statement, a MAP, some global equates and data, a file definition, and a CODE statement to kick off execution (and yes, to save space I've left off the definitions of the procs declared in the map). And then you have a couple of lines that again look a bit different.

Application is actually System.Windows.Forms.Application, a special class which you cannot derive, and which manages the WinForms application. The first method call enables visual styles, and the second call, the Run method, launches an instance of the MainForm object.

At this point things start to get just a little different. MainForm is actually a class, not a procedure, and it's derived from System.Windows.Forms.Form. You won't see an INCLUDE statement anywhere because it isn't needed; as long as MainForm is in the same project, that's enough.

MainForm, which contains the application frame and associated menu, is contained in two files. Figure 5 shows the project tree for PEOPLEApp.

Figure 5. The PEOPLEApp project tree

As you can see there's a MainForm.cln file, and a MainForm.Designer.cln file. Together, these files make up the MainForm class code.

You're probably familiar with how Clarion separates classes into prototypes (INC files) and implementation (CLW files). This is something different, and it's called a partial class.

Partial classes

A partial class is a .NET feature whereby you can declare part of a class in one file, and another part in another file. One of the reasons for doing this is to make it easier to separate presentation (user interface) code from business logic. In Clarion.NET, as in C# and VB.NET, when it comes to window handling one part of the partial class is the bit where you add your code, and the other part is managed by the window designer.

Here are a couple of methods from the business logic half of the MainForm class (in MainForm.clw):

MainForm.peopleDataGridToolStripMenuItem_Click |
  PROCEDURE(System.Object sender, System.EventArgs e)
W &peopleDataGridView
    CODE
       W := NEW peopleDataGridView()
       W.MdiParent := SELF
       W.Show()

MainForm.peopleBrowseToolStripMenuItem_Click |
  PROCEDURE(System.Object sender, System.EventArgs e)
W &peopleBrowse
    CODE
       W := NEW peopleBrowse()
       W.MdiParent := SELF
       W.Show()

And here are a few methods from the window designer half of MainMenu (in MainForm.Designer.cln):

SELF.menuStrip := NEW System.Windows.Forms.MenuStrip()
SELF.fileToolStripMenuItem := |
  NEW System.Windows.Forms.ToolStripMenuItem()
SELF.printPreviewToolStripMenuItem := |
  NEW System.Windows.Forms.ToolStripMenuItem()
SELF.toolStripSeparator2 := |
  NEW System.Windows.Forms.ToolStripSeparator()
SELF.exitToolStripMenuItem := |
  NEW System.Windows.Forms.ToolStripMenuItem()
SELF.editToolStripMenuItem := |
  NEW System.Windows.Forms.ToolStripMenuItem()
! ...
SELF.menuStrip.Items.AddRange(NEW System.Windows.Forms.ToolStripItem[]|
  {SELF.fileToolStripMenuItem, SELF.editToolStripMenuItem, |
  SELF.dataGridToolStripMenuItem, SELF.browseToolStripMenuItem, |
  SELF.reportToolStripMenuItem, SELF.windowToolStripMenu, |
  SELF.helpToolStripMenuItem})
SELF.menuStrip.Location := NEW System.Drawing.Point(0, 0)
SELF.menuStrip.MdiWindowListItem := SELF.windowToolStripMenu
SELF.menuStrip.Name := 'menuStrip'
SELF.menuStrip.Size := NEW System.Drawing.Size(592, 24)
SELF.menuStrip.TabIndex := 0
SELF.menuStrip.Text := 'menuStrip'

As you can see, the business logic side determines what happens when the user clicks on a menu item, while the designer side creates and lays out the menu items.

What this means is that the window designing process, as far as the IDE and the runtime goes, is quite different from how it works in WinAPI Clarion. What we're used to is a WINDOW structure which is read by the designer, and which the compiler turns into a bunch of Windows API and runtime library calls to create and display the window. In Clarion# the window "structure" is actually stored using exactly the same code as will be needed at runtime to create and display the window.

There's a third file that can come into play in any window, and that's the resource file. This is an XML file specifying how images and other resources are to be handled, and it has the extension resx. Here's some code that loads an image from a resource file:

SELF.toolStripButtonClose.Image := |
  ((resources.GetObject('toolStripButtonClose.Image') |
  TRYAS System.Drawing.Image))

Reports

Unlike windows, Clarion.NET's report structures look pretty much unchanged, but with browses and forms, each report is a CLASS not a PROCEDURE. Basically a report opens a progress window, starts a timer, and on each timer tick prints a report detail:

peopleReport.Timer_Tick PROCEDURE(System.Object sender, |
                                   System.EventArgs e)
 CODE
    IF NOT SELF.Print()
      SELF.Close()
    END

peopleReport.Print PROCEDURE()
 CODE
    SELF.RecordsThisCycle = 0
    LOOP SELF.RecordsPerCycle TIMES
         IF SELF.GetNextRecord()
            IF SELF.ProcessCancelled = false
               PRINT(SELF.detailBand)
            END
         ELSE
            SELF.timer.Stop()
            SELF.timer.Enabled := false
            RETURN False
         END
    END
    RETURN true

Keep in mind that this is a pretty simple report with just one detail.

Help! It's all OOP!

While the Clarion# code generated by the C6 wizard is salted with procedural code, the fact is that, yes, it is almost all object-oriented code. So what does that mean to you, if you don't know OOP at all, or aren't very comfortable with OOP?

It seems to me that OOP in Clarion# is a lot like OOP in ABC. If you can get by with ABC and AppGen, then you can probably get by in Clarion# as well. But you'll really be missing out on the power and flexibility of the .NET framework if you don't understand object-oriented programming. It's like travelling in a foreign country. You can get by with a phrase book, but you'll have a lot more fun and a lot less trouble if you can speak the language. You may want to get started by reading the three part series The ABCs of OOP; also keep your eyes open for Clarion# tutorials coming up in the magazine.

Data binding

In WinAPI applications you typically load data from a file into a queue, and then you link that queue to a list box with the FROM attribute. The queue is bound to the list control - change the data in the list box and the displayed data instantly changes accordingly. This is an example of data binding - the data store (in this case the queue) is tightly connected to the visual control (the list box). But how it all happens is hidden from the developer in a Clarion WinAPI application.

.NET takes the concept of data binding quite a lot further, exposing the plumbing and allowing a wide variety of classes to function as data sources for controls. Sample projects shipped with the beta demonstrate how to bind not just a queue to a control, but also a record and a file.

Visuals

Clarion.NET applications look marginally different from Clarion WinAPI applications. Figure 6 shows the Clarion.NET version of the people app, and Figure 7 shows the Clarion WinAPI version.

Figure 6. A Clarion.NET People application

Figure 7. A Clarion WinAPI People application

There are some obvious differences not just due to the platform change. The older app has a navigation toolbar and large Insert/Change/Delete buttons, as well as a Print button, sorting tabs, and a status bar. The .NET app has a local toolbar and a VCR control. That doesn't mean the .NET app can't have tabs and buttons and all that, it just means the template wizard writer didn't put that stuff in.

There are some more subtle differences in the visuals as well. The list box headers are drawn differently, and the scroll bars, finally, are sized according to the portion of the data shown in the control (although I think you can expect that to work a little differently for page-loaded list boxes). There's also a gentle gradient in the background window color on the .NET browse (possibly because of the toolbar), while the older browse window is a solid color. If you mouse over menu items, buttons or column headers they will change color (at least on Vista - on my machine the highlight color is blue, presumably a feature of the color scheme I've chosen).

This is all pretty plain Jane Clarion stuff so far, but even Clarion is getting into the act. Figure 8 shows SoftVelocity's new glass buttons.

Figure 8. Glass buttons on image background

Hover your mouse over a glass button and you'll see a glowing highlight; hover over a flat button and the button outline appears. Click on the button and the background darkens. Figure 9 shows the buttons without the image background.

Figure 9. Glass buttons on white background

If the standard controls supplied by SoftVelocity and the .NET framework aren't good enough for you, there are a great many custom controls available as well (and of course you can create your own custom controls). Couple all that with .NET's data binding capabilities and you have a full toolbox for tackling the most unusual data management problems.

Summary

Clarion.NET is clearly a huge step forward for Clarion development. Yes, it's still in beta, and there will be bugs to squash, and we're still waiting on AppGen. But this is a real, working, .NET language. It's a triple crown of desktop, web, and mobile programming, all solidly in the mainstream of Windows technology. Clarion has never had that before.

---

David Harms is an independent software developer and the editor and publisher of Clarion Magazine. He is also co-author with Ross Santos of Developing Clarion for Windows Applications, published by SAMS (1995), and has written or co-written several Java books. David is a member of the American Society of Journalists and Authors (ASJA).

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942