Components4Developers have been given special permission by CodeGear to talk about the Highlander field test release.

In this third blog entry about the CodeGear Highlander pre-release I'm going to demonstrate a full kbmMW native Delphi client in operation.

It is going to call a windows 32bit kbmMW server that has a service supporting three operations for this demo.

1. A simple echo remote procedure call

2. Streaming a TkbmMemtable down the wire to the client

3. Execution of a named query that returns a list of C4D products form a SQL Server 2005 database

Below is the user control I designed in Highlander for the three demos

1. A simple echo remote procedure call

Here is the code for the Ping button

To make things simpler I encapsulated the wiring up of the TCP/IP transport into a connector class to declutter these samples.  This simple demo sends the content of the text box and sends it to our service named KBMMW_QUERY for processing my the method PingServer.  PingServer simply returns the text sent to it as argument 0.  We take the return value and update a lable to the right of out ping button.

Here's the result

2. Streaming a TkbmMemtable down the wire to the client

The server being used for these demos is the same one used when developing Spider 2 - our extended C# client.  On our service we have a method called GemMemtable that creates and defines a TkbmMemtable in the fly and populates it with two records.  The whole memtable structure and data is then formatted onto the resultstream and sent down the wire.  At the client we must do the reverse.

For this sample we perform the decode into a local TkbmMemtable and then bind that to a grid to visualise the result.  Here is the code

Once again we call our service but this time we execute the method GetMemtable. After the call the data from our server resides in the stream client.resultstream.  We create a formatter, in this case the kbmMW formatter, and populate a TkbmMemtable using it.  This can be seen in the line memtable.LoadFromStreamViaFormat(client.ResultStream,formatter)

After this point we have our TkbmMemtable correctly structured and populated with data from the server.  Because of the dotnet extensions I talked about in blog 2 I can bind this directly to the standard ASP.net Gridview control.

Here is the result:

3. Execution of a named query that returns a list of C4D products form a SQL Server 2005 database

kbmMW users will be familiar with the concept of named queries.  We want to promote good n-tier practices where business knowledge is encapsulated at the server and not the client.  Named queries promote this by allowing clients to execute a query by name without needing any knowledge of the SQL that will execute.

Here is the code:

In this sample we create a TkbmMWClientQuery to accept the data from our server.  We bind it to a formatter, in this case the TkbmMWBinaryStreamFormat, and set it's Query text to be our named query @highlanderDemo.  Next we simply call Open and the rest is automatic.  Once more we bind the result to a gridview.  The named query that our client had no knowledge about lists the products available on myc4d.com.  Here is the result:

One final note to end with and this is mainly of interest to kbmMW users.  During the very early phase of the Highlander FT there was no Indy 10 assembly to use.  In order to progress we wrote our own native Delphi socket client.  Here is a snippet of the client connector encapsulation used for these demos where you will notice the new transport TkbmMWTCPIPDotNetClientTransport :

A final final note.  Highlander has been great in terms of code compatibility.  Almost all the codebase has ported without much effort. Most changes have been due to alterations in the dotnet framework itself.  A good sign.

Richard

Components4Developers have been given special permission by CodeGear to talk about the Highlander field test release.

A project that I have running which has slipped on our release schedule is kbmMemtable dotnet extensions.  This uses the standard TkbmMemtable with some special plug-in extensions.  The extensions are relevent to dotnet only and extend the memtable to be fully bindable in dotnet.  I had this running under dotnet 1.1 built using BDS2006 but wanted to take it further by re-optimsing some of the memtable internal structures to boost it's speed and capabilities.  Unfortunately at the time the internal restructuring I had in mind used features only available in dotnet 2.0 hence the slip. 

Now that Highlander has come along I've re-visited my project. After rebuilding my assembly with the plugin extensions I created a new ASP.net project and added a reference to it - kbmMemProD2007dnRun.dll in this case.

I then added some code into the page_load event of the default WebForm1.aspx where I create a kbmMemtable and add three fielddefs to it.  These are of type String, Integer and Float.

I then Open the table and add 20 records to it.  My page contains a DataGrid and once I've added my records to the memtable I bind it to the datagrid.

Here is a screenshot of the running application:

So - some might wonder what the big deal is?

Well there are a few things going on. 

1) kbmMemtable is running under dotnet 2

2) we're able to bind kbmMemtable as a datasource to standard dotnet controls

3) kbmMemtable is still a TDataset descendent and hence can be bound to any VCL.net control too

4) kbmMW queries are descended from TkbmCustomMemtable - hence kbmMW resultsets also support 1, 2 and 3 above.

In combination with Spider 2 that I blogged about last time I hope you can see it is now possible to pass around and work with kbmMemtables on dotnet 1.1, 2.0 and 3.0, win32 and linux.  More to the point - you can choose to visualise the data using any combination of VCL, VCL.net, WinForms or ASP.net controls/components. 

My next blog will show kbmMW working in Highlander. 

Richard