Clarion

T4 templates have a simple ASP.NET-like syntax and consist of processing directives, text blocks and code blocks. For this discussion we’re using the attached DCTTreeWizard.tt file which is a Utility template. Download it from here

We have two types of Utility Templates; DCT Utility Templates and ApplicationUtility Templates. Within the IDE when the “Document” tab that has focus is a .DCT or an .APPX the “Run Utility Template” menu item under the File menu is enabled, and depending on the type of the active document, the “Run Utility Template” Menu item will show a Selection Dialog displaying the appropriate Utility Templates for the document (DCT Utility Templates or Application Utility Templates) The big difference between a standard template and a Utility Template, is that the when the Utility Template is executed, the code will not output any text/code automatically. The template developer must define the output using the built-in Open/Close or Create/Close methods.

The DCT Utility template focuses on the DataDictionary object. The DataDictionary object is of type IDataDictionary, and using the IDE’s code completion we can learn how to use it; seeing its properties and methods with the complete descriptions. The DataDictionary object is very straight forward and easy to undertand. For example, it’s likely pretty clear that “this.DataDictionary.Tables” returns all the tables defined in the Dictionary.

The Application Utility template also has the DataDictionary object, but it has another object called “Application”. And of course you can query “this.Application.Procedures”, and guess what that returns? Yes you guessed it, all the procedures defined in that .APPX file.

Let’s do a walk-through of our simple DCT Utility template.

We’ll start with a look at Directives. The syntax of a directive is:

<#@ DirectiveName [ParameterName = "ParameterValue"] #>

for an example look at line 1 from the attached template:

<#@ template language=”C#” debug=”true” type=”Utility” name = “DCTTreeWizard” chain=”Clarion.File”#>

The “language” parameter specifies which language is used in the code blocks of the template, and in this case we specify C#.

The “debug” paramater allows you to debug templates. When that parameter is on, and the corresponding IDE option is also on, the template source code files are copied to the %root%\..\Templates\dotnet folder. And when there is an error in compiling the template (compilation occurs when you register the template), the error is displayed in the Error pad, and you can then double-click on the error and the .TT file with the error is opened for editing at the line with the error.

The “type” parameter specifies the type of template, current possible types are:
Application,
Procedure,
ApplicationExtension,
ProcedureExtension,
Utility,
UtilityApplication,
WizardApplication,
WizardProcedure

The “name” parameter assigns a name to this template, and finally the “chain” parameter specifies the template family.

Lines 2-6 use the “assembly” directive:
<#@ assembly name=”mscorlib.dll” #>
<#@ assembly name=”System.dll” #>
<#@ assembly name=”System.Drawing.dll” #>
<#@ assembly name=”System.Design.dll” #>
<#@ assembly name=”System.Drawing.Design.dll” #>

The “assembly” directive identifies an assembly to be referenced by the template so that you can use types within that assembly from within the code in your template. Using the assembly directive is equivalent to using the Add Reference feature in the Clarion# IDE. The “assembly” directive does not affect the source code of the compiled template.

Lines 7-12 use the “import” directive.
<#@ import namespace=”System.Collections.Generic” #>
<#@ import namespace=”System” #>
<#@ import namespace=”SoftVelocity.TextTemplating” #>
<#@ import namespace=”System.Drawing” #>
<#@ import namespace=”System.Drawing.Design” #>
<#@ import namespace=”SoftVelocity.DataDictionary.Design” #>

The import directive allows you to refer to types within a text template without providing a fully qualified name. The “namespace” parameter is transformed into a .Net “using” directive in the compiled template.

Now look at line 13:
<#@ property processor=”PropertyProcessor” name=”OutputFile” type=”System.String” defaultValue=”none” editor=”System.Windows.Forms.Design.FileNameEditor”#>

The “property” directive defines an editable property of the template. It corresponds to #PROMPT in our Win32 template language. The parameters are probably self-explanatory; “name” is the name that is displayed in the property grid, “type” defines what type of value is accepted, “defaultValue” is exactly as the name suggests, and “editor” is the object that is used to visually edit the property. The “editor” can be just the default; a simple text string, but it can also be a dialog window, a dropList, a checkbox, or by default a simple textBox.

Line 14 is interesting: <#+ string _OutputFile = “”;#>

the <#+ tag indicates a template helper block. The helper block allows the template developer to add code at the TextTransformation Class level. The code added can be a Method, a Field, or a Property declaration.

If a Method is declared within the helper block, it can be compared to a #GROUP from our Win32 template language. Embeds can also be declared inside a helper block.

for example:

<#+ void MyPseudoGroup() {#> <#% MyEmbed #> <#+}#>

In this case when the method MyPseudoGroup is called, the content of the MyEmbed will be also executed.

Line 15: <# this._OutputFile = this.OutputFile;#>

just the value set in the “OutputFile” within the property directive to the internal _OutputFile variable.

Line 16: <# Create(this._OutputFile);#>

calls an internal method that creates a file on disk to receive the generated text (code or other text). It corresponds to our Win32 counterpart #CREATE.

Line 17:
*************************

is a text block, as there are no template directives surrounding it. Text blocks are copied to the output “as is”, with no further processing.

Line 18: - Listing for Dictionary: <#= this.DataDictionary.FileName #>

mixes a text block: ‘- Listing for Dictionary: ‘ with an expression block:
<#= this.DataDictionary.FileName #>

You use expression blocks in text templates to add strings to the generated text output. In this case we’re asking for the name of the Dictionary that we’re processing. Expression blocks are delineated by using the <#= template tag. The syntax is: <#= ExpressionCode #>

Lines 19-49 use code blocks. The syntax for a code block is: <# Code block #>

Code blocks can generate template output. In our template the code block uses a few nested foreach loops to walk the dictionary. We’re using a mix of text blocks and expression blocks to write the details of the dictionary to the output file. Code blocks can use any available .NET APIs. In this template we’re using the DataDictionary API to output the Dictionaries collections and properties; Tables, Columns, Keys and Relationships.

I hope this walk-through has provided a good introduction to the new template syntax used in AppGen.Net.  For those who are thinking of writing some T4 templates the attached example is a good starting point to get familiar with the essentials. Next time we’ll go a bit deeper into the template syntax.

In this post I’ll try to provide a complete overview and our best estimate on when you’ll have this new technology in your own hands. Diego Borojovich is leading the team working on the new .Net Application Generator (AppGen.Net), and if you have attended any DevCon events over these last years then you probably have met Diego. He’s been working with Clarion for over 16 years, and joined the SoftVelocity development team 8 years ago. You’ll be hearing a lot more from Diego in blog posts in the upcoming weeks as he talks in-depth about the new AppGen.Net, the template language, and how the new code generation/template system works.

Let’s start from the top; the Code Generation engine in AppGen.Net is completely new. It has its architectural and conceptual roots in the Clarion Win32 AppGen, and that technology is blended with the functionality found in the Text Template Transformation Toolkit (T4).

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.  It uses an extended set of the T4 template directives. It’s very easy to work with the template code and templates can be used in any type of project (WinForm, WebForm, CompactForms, Web Services, etc.). And just like with our Win32 AppGen you can write templates to create any type of output that you need – CLN, CS, ASPX, HTML, SQL, XML, or anything else you need.

The syntax for the new templates is similar to what you see in an ASP.NET .ASPX source file – here’s a small snippet so that you get a feel for what it looks like:

<#@ template language=”C#” debug=”true” type=”ProcedureExtension” name = “DescriptionOutput” family = “Clarion.Linq”#>
<#@ assembly name=”mscorlib.dll” #>
<#@ assembly name=”System.dll” #>
<#@ import namespace=”System” #>
<#@ import namespace=”SoftVelocity.TextTemplating” #>
<#@ property processor=”PropertyProcessor” name=”MyDescription” type=”System.String” defaultValue=”None”#>
<#%+ CustomGlobalData priority = “1000″#>

I already mentioned that the AppGen.Net template system supports an extended set of the T4 template directives, these extended directives include equivalence for our #PROCEDURE, #CODE, #GROUP, #CONTROL, #EMBED and #AT and #EXTENSION directives as found in our Win32 template system. And you may have noticed in the first line of the template snippet where it reads “template language=C#”? In the first release, all the templates are coded in C#, but in a future release we plan to let you use any .Net language to write your own templates. The templates themselves can utilize the entire .Net Framework, including any 3rd party components, and that gives us (and you) incredible power and flexibility in the template system; meaning there are really no limits to what you can do in a template (outside of is your own imagination). If you plan on writing templates you’ll be glad to know that inside the IDE we already have T4 syntax highlighting in the editor, and in the near future we’ll be adding code completion support.

The template system has the concept of a template registry, just as we have now. But with AppGen.Net when templates are registered into the IDE they are automatically compiled into a binary assembly. Compiling the templates provides for faster code generation, immediate detection of syntax errors, and makes it easy to share templates within a team.

In the initial public release the generated data access layer will let you select from two data access frameworks; LINQ to File, and LINQ to SQL.  (It’s possible that we will also provide a template set for generating a plain ADO.NET data access)

What is LINQ to FILE?

LINQ to FILE utilizes our own LINQ provider that encapsulates an ABC-styled framework — using LINQ syntax for accessing and updating data via our underlying File Driver technology. The LINQ to FILE provider maintains referential integrity and also handles auto incrementing of keys. The LINQ to File data access layer can also utilize our managed .Net IP driver. If you’re not already familiar with LINQ syntax here is a simple example of the syntax used for retrieving data:

query? = from class in ClassesQuery    |
where class.RoomNumber < 10   |
select class

This LINQ query will retrieve all records where the column RoomNumber is less then 10, it’s really that simple. And using a LINQ query with a Where clause instead of filtering records in a Loop provides a noticeable increase in performance. Using the LINQ to File lets us work with powerful SQL-like query and update capabilities, working with all of our FILE Drivers, and integrated into the LINQ to FILE provider is functionality essentially equivalent to that in our existing ABC framework.

What Is LINQ to SQL?

LINQ to SQL is itself a light-weight ORM (object relational mapping) implementation that ships as part of .NET 3.5, that allows you to model a relational database using .NET classes.  You can then query the database using LINQ, as well as update/insert/delete data from it. LINQ to SQL supports transactions, views, and stored procedures.  The templates provide an easy way to integrate data validation and business logic rules directly into your data model.

In addition to the two LINQ frameworks we plan to add template support for working with several additional technologies for the data access layer;  options for data access will look like this:

•    LINQtoFile
•    LINQtoSQL
•    ASP.NET MVC
•    NHibernate
•    CSLA
•    ADO.Net

We also plan to have templates for supporting these technologies:

•    Windows Communication Foundation (WCF) is the .Net programming model for building service-oriented applications.
•    Web Services (for exchanging data)

And I should mention that we’re providing template sets to support the three target platforms; Winforms (desktop), WebForms (Web) and Compact Forms (Mobile devices). The templates being developed for .Net offer code generation in 2 language flavors C# and Clarion#, and eventually we’ll add VB to the list.

I want to mention a few things about the user interface generated by the templates. These are options that the templates will provide for the user interface layer:

•    Winforms (using the standard .Net Framework controls, or a designated 3rd party component set)
•    CompactForms (using the standard .Net Framework controls, or a designated 3rd party component set)
•    Webforms (using the standard .Net Framework controls, designated 3rd party component set, Ajax Library, and in the future Silverlight)
•    WPF - Windows Presentation Foundation: (using the standard .Net Framework controls, or a designated 3rd party component set)
(The WPF support will come after the initial release, and although we don’t presently have a full-blown designer, we will have UI edit capabilities, and of course you can use many different external tools to create and work on the UI as the code is completely separate from the other layers)

For creation of the UI the templates read the control settings from the Dictionary, just as we do now in the Win32 AppGen, but we plan to provide (as a configuration option) the ability to specify that the templates use an external file for control mappings, and in this file we’ll store the fully-qualified name of the control, along with its properties (i.e. font, width, height, etc.). The controls specified in the config file will map back to the controls supported in the templates for generating the UI. This feature means that you can specify the use of 3rd party components and the Template Wizards will generate the UI using those controls and properties.

Here are a few miscellaneous new features that are worthy of mention which are planned to be introduced with the new AppGen.Net:

•    Option to generate test cases (nUnit) for aspects of the APP
•    Ability to attach developer documentation/working notes directly into the .APP and/or to individual procedures

And something else exciting is coming up; we are happy to announce that the templates to power these technologies will be made part of an open collaborative community project so that anyone interested can participate in their ongoing development. This collaborative project will contain all of the new Clarion templates and sample Apps.

And this project is not just for the new .Net templates, we’ll be adding all of our Clarion templates (Win32 and .Net), as well as new example Apps. With this project the Clarion community will always have access to the very latest updates, as well as contribute patches, and add new templates and sample Apps.

Now the question at hand is when will you get it?  We have had to revise our earlier estimates to allow extra time for some of the integration tasks in our switch over to the new AppGen.Net, and the revised estimate for delivering a full beta is now about 5-6 weeks from today, putting it into a late-May early-June time frame. However, it is very likely that we’ll release the new AppGen.Net with some reduced template support before that. That first early release will support generation of code targeted at the data access layer, in other words it will be without the tie-in with the Designers. And that release also will likely include Application and Procedure Wizard functionality. So that first release will provide a big increase in productivity in two areas, and it’ll also allow those who are interested, to start working on the template code itself. Very importantly it’ll also let us get feedback from you on the AppGen.Net UI itself, which is very valuable to us all.

We have a new update on its way to you.  This release solidifies the new LinqToFileProvider and has some good general fixes. We’re getting closer with the new App code generator and we will keep you posted on how its progressing.  We’re also getting close to where we’ll open up weekly or bi-weekly internal builds.

We’ve received some requests via email that have prompted us to start a new project this week; a secured website membership component. We have two goals to accomplish; first we’ll provide the ability to log in to our website and download products that you own, retrieve serial numbers for same, and get the newest updates to the Help files, and second you’ll be able to log in and have access to pre-release internal builds. We’ll make internal builds available for both Clarion 7 (Win32) and Clarion# (.Net). We have started the work on an implementation of a website membership project to be built on top of ASP.NET’s SQLmembership Provider with the UI built with AJAX. We’ll be using it to control the access to the product downloads and to the internal builds, and we’ll also be shipping the secured website membership component as source code with Clarion.Net (and of course we’ll be using it with the .Net App generator).

Access to internal builds will be open to anyone with a current subscription. Once the project is launched we’ll initially try to make internal builds available on a bi-weekly basis (weekly builds are also a possibility). You’ll have access to the change log, and if you see a fix or a feature become available that’s important to you – you’ll have the option to download the corresponding internal build. And by the way, if there happens to be a change to the RTL or compiler that would require your 3rd party tools be rebuilt (this is a fairly rare occurrence), it’ll be duly noted in the change log.

We’ll also be increasing the frequency of publishing maintenance releases (this too was requested in several emails), and we expect to make a new 7.1.x release available at the end of this week.

Note: This blog was written by Robert Ricketts, who is a Senior Support Representative at SoftVelocity. If you have any questions, you can post them here or even email us at support AT softvelocity DOT com

Now, on to the article!

There has been quite a bit of confusion about using the 32 ODBC Administrator and 32 Bit ODBC drivers in 64 bit Operating Systems so I thought I would put together some information to help when using 32 bit ODBC drivers, such as the TopSpeed ODBC driver.

For 64 bit Operating Systems, there is a 64 bit and a 32 bit ODBC Source
Administrator.  Both actually have the same name (odbcad32.exe).

You can launch the Admin applet from the command line (or a Shortcut) so you get the 32-bit version of the ODBC configuration tool. The command line is as follows:

%WINDIR%\SysWOW64\odbcad32.exe

Microsoft stores the 32 bit odbcad32.exe in the syswow64 directory and the 64 bit odbcad32.exe in the system32 directory.

N.B. If you just run odbcad32.exe, Windows will actually run the 64-bit version because the default system path has system32 ahead of syswow64.

From: http://support.microsoft.com/kb/942976

System DSNs are stored in the following registry subkey:
HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI

Registry redirection is enabled for this registry subkey. Therefore, system
DSNs for 32-bit drivers and for 64-bit drivers are separated. The 64-bit ODBC Administrator tool does not display the system DSNs that are created by the 32-bit ODBC Administrator tool or that use 32-bit drivers and visa versa.

User DSNs are stored in the following registry subkey:
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI

Registry redirection is not enabled for this registry subkey. Therefore, both
ODBC Administrator tools display all user DSNs.

Regarding the DotNet Framework

In order to use the TPS ODBC driver from .NET you will need to use the .NET Framework Provider for ODBC.

If you see no reference to the .Net Framework Provider for ODBC, this is
available as a free download from:

http://www.microsoft.com/downloads

Search for “ODBC .Net Data Provider” to download and install the .Net Framework Provider for ODBC.