This post shows a version of FillList which can work with enumerable objects such at TStrings or TList<> (an object is enumerable if it implements GetEnumerator).   TBindScope is used instead of TBindScopeDB.  

Here is a FillList method which can populate a list control from an enumerable object: 

procedure FillList(AControl: TComponent; const AControlExpression: string;
  AEnumerableObject: TObject; const ASourceExpression: string); overload;
var
  LBindList: TBindList;
  LBindScope: TBindScope;
  I: Integer;
begin
  LBindScope := TBindScope.Create(nil);
  LBindList := TBindList.Create(nil);
  try
    // Turn off auto properties.
    LBindList.AutoFill := False;
    LBindList.AutoActivate := False;
    LBindList.ControlComponent := AControl;
    // Scope references the enumerable object
    LBindScope.DataObject := AEnumerableObject;
    LBindList.SourceComponent := LBindScope;
    with LBindList.FormatExpressions.AddExpression do
    begin
      SourceExpression := ASourceExpression;
      ControlExpression := AControlExpression;
    end;
    LBindList.FillList;
  finally
    LBindList.Free;
    LBindScope.Free;
  end;
end;

Call FillList as follows to populate a ListBox or ComboBox with the values from a TStrings:

procedure ListStrings(AListControl: TControl);
var
  LStrings: TStrings;
begin
  LStrings := TStringList.Create;
  try
    LStrings.DelimitedText := 'one,two,three,four,five,six';

    FillList(AListControl, 'Text', LStrings, 'Current');
  finally
    LStrings.Free;
  end;
end;

‘Text’ references the list item text.   ‘Current’ references the property Current of TStringsEnumerator.

Instead of TStrings we can also use a generic collection of string:

procedure ListStrings(AListControl: TControl);
var
  LStrings: TList<string>;
begin
  LStrings := TList<string>.Create;
  try
    LStrings.AddRange(
     TArray<string>.Create('one','two','three'));

    FillList(AListControl, 'Text', LStrings, 'Current');
  finally
    LStrings.Free;
  end;
end;

And also a generic collection of object:

type
  TSampleObject = class
  private
    FStringProp: string;
    FIntegerProp: Integer;
  public
    constructor Create(AIntegerProp: Integer);
    property StringProp: string read FStringProp;
    property IntegerProp: Integer read FIntegerProp;
  end;

procedure ListSampleObjects(AListControl: TControl);
var
  LList: TList<TSampleObject>;
  I: Integer;
begin
  LList := TObjectList<TSampleObject>.Create; // Owns objects
  try
    for I := 1 to 10 do
      LList.Add(TSampleObject.Create(I));

    FillList(AListControl, 'Text', LList, 'ToStr(Current.IntegerProp) + ": " + Current.StringProp');
  finally
    LList.Free;
  end;
end;

As mentioned in the previous post,  you will need to use FMX.Binding.Editors. For VCL projects, use VCL.Binding.Editors.

A sample project using FillList is available on sourceforge:

Share This | Email this page to a friend

Here is a method to fill a listbox using a TBindList component:

procedure FillList(AControl: TComponent; const AControlExpression: string;
  ASource: TBaseBindScopeComponent; const ASourceExpression: string; const ASourceMemberName: string = '');
var
  LBindList: TBindList;
begin
  LBindList := TBindList.Create(nil);
  try
    // Turn off auto properties.
    LBindList.AutoFill := False;
    LBindList.AutoActivate := False;
    LBindList.ControlComponent := AControl;
    LBindList.SourceComponent := ASource;
    LBindList.SourceMemberName := ASourceMemberName;
    with LBindList.FormatExpressions.AddExpression do
    begin
      SourceExpression := ASourceExpression;
      ControlExpression := AControlExpression;
    end;
    LBindList.FillList;
  finally
    LBindList.Free;
  end;
end;

You will need a TBindScopeDB component which is connected to a TDataSource. Call FillList as follows to populate a listbox with the value of the Category field:

  FillList(ListBox1, 'Text', BindScopeDB1, 'AsString', 'Category');

When using this code in a FireMonkey project, you will need to use FMX.Bind.Editors. For VCL projects, use VCL.Bind.Editors.

These units register editors which TBindList uses to add items to a TListBox. These units also register editors for a TComboBox.  Use the following line of code to populate a combo box.

  FillList(ComboBox1, 'Text', BindScopeDB1, 'AsString', 'Category');

VCL.Bind.Editors also registers an editor for TListView.  Use the following line of code to populate a list view:

  FillList(ListView1, 'Caption', BindScopeDB1, 'AsString', 'Category');

The last parameter to the FillList method is optional. When excluded, TBindList will evaluate against TDataSet instead of TField.  The following code fills a listbox with values from two different fields:

  FillList(ListBox1, 'Text', BindScopeDB1, 'Category.AsString + " - " +  Common_Name.AsString');

A sample project showing how to implemet and use the FillList method is available on sourceforge:

Share This | Email this page to a friend

TBindList can iterate through the records in a TClientDataSet and fill a TListBox.  Here is how to configure TBindList in the designer.

Drop a TClientDataSet and a TDataSource on a form.  Load some data into the dataset such as biolife.xml (Right click ClientDataSet1, choose "Load from MyBase table…", browse to the sample data directory and choose biolife.xml).   In the object inspector, set DataSource1.DataSet to ClientDataSet1.  Drop a TBindScopeDB component on the form and set BindScopeDB1.DataSource to DataSource1. 

BindScopeDB1 connected to DataSource1

New LiveBinding... command for ListBox1

Click "New LiveBinding…" and choose TBindList.

New LiveBinding dialog box

Double click or press OK.  The New LiveBindings dialog creates a TBindingsList component and a TBindList component.  TBindingsList is a container for binding components just as TActionList is a container for actions.  Double click on TBindingsList to see the new TBindList component.

TBindingsList contains a TBindList component

Click on BindListListBox11 to show the properties of the new TBindList component.   The ControlComponent property was set to ListBox1 by the "New LiveBinding…" command.

BindList1 with ControlComponent set to ListBox1

Use the object inspector to set the SourceComponent to BindScopeDB1.  Set SourceMemberName to the name of a field.  The SourceMemberName property editor should provide a drop down list of field names.  If not, then the data components are probably not connected (DataSource1.DataSet must be set to ClientDataSet1 and  BindScopeDB1.DataSource must be set to DataSource1).

BindList1 SourceComponent and SourceMemberName

The final step is to enter the binding expressions.  Open the expressions editor by clicking the "Expressions…" command at the bottom of the object inspector.

BindList1 Expressions Editor

Select the "Format" collection and click the "Add Expression" button to add a new binding expression.  Enter "Text" as the control expression.  Enter "AsString" as the source expression.

BindList1 Format binding expression

Be sure that you’ve added to the "Format" collection and not the "FormatControl" collection. 

The buttons at the bottom of the window are used to test the expressions.  Click "Eval Source" to evaluate the expression "AsString" against the Category field.

Expression Result Window

Close the Expression Result window.  Also close the expression editor. 

At the bottom of the object inspector are two commands for trying out TBindList at design time.  Click "Fill List" to populate ListBox1.

BindList1 fills ListBox1

Now click "Clear List".

Run the project.  ListBox1 is populated with the values of the Category field. 

Share This | Email this page to a friend

Samples from "DataSnap Tooling" (Wednesday, September 9 at 7 pm PDT) are available here: http://cc.embarcadero.com/Item/27221.

Samples from "DataSnap Server Method Table Parameters" (Thursday, September 10 at 6 pm) are available here: http://cc.embarcadero.com/Item/27222.

Share This | Email this page to a friend

Click these links to skip ahead Configure IIS, Connect with Data Explorer, Ancestors and DataModules, ISAPI debugging

In the File/New… dialog, double click “DataSnap WebBroker Application”

Check “ISAPI/NSAPI Dynamic link Library”,  “Add Server Methods Class” and “Include sample methods”.

Select TPersistent as the ancestor class for the server methods.  I will say more about the ancestor choices later in this post.

Click OK to create a new project.

The new project has two units.  ServerMethodsUnit implements the server methods for this DataSnap server.  There is a single server method called EchoString with a string parameter (see my previous posts to learn more about server method parameter types).

The WebModule contains the components that make this ISAPI dll function as a DataSnap 2010 HTTP server. 

DSServer1 and DSServerClass are the same components used in stand alone TCP/IP DataSnap servers.   DSHTTPWebDispatcher is new to  DataSnap 2010.  It is responsible for managing ISAPI/WebBroker HTTP requests and responses on behalf of the DataSnap Server. 

Both DSHTTPWebDispatcher1 and DSServerClass1 components have their “Server” property set to “DSServer1”.  The DSServerClass1 component calls an event handler to get the type of the server methods class:

The wizard has generated a complete ISAPI application so no changes are required to the project source code, however I do need to configure IIS.  

Configure IIS

Here is how I configure IIS 6.0 on my Vista x32 system.

If you haven’t enabled IIS on your system then use “Programs and features”/”Turn Windows features on or off” to install.

Start Internet Information Services (IIS) Manager.

Expand Connections nodes, right click on “Default Web Site”, choose “Add Virtual Directory”.

Enter an alias of “DSProject” an a physical path of "c:\DSProject".

ISAPI must be enabled for this virtual directory.  Select the “DSProjects” Connections node.  Double click the “Handler Mappings” icon.  Click Actions/“Edit Handler Permissions…”.  Check “Execute”.

Directory browsing is convenient but not required.  Enable it for this example.  Select “DSProjects” Connections node.  Double click the “Directory Browsing” icon.  Click Actions/”Enable”.

Almost done configuring IIS.  Click on the root Connection node.  Double click the “ISAPI and CGI Restrictions” icon.  Click Actions/”Edit Feature Setting…”.  I have “Allow unspecified ISAPI modules” checked.  If you don’t check this then you will need to add to the list of ISAPI dlls recognized by IIS, after you have built your project. 

Now go back to Delphi 2010 and set the output directory to the virtual directory physical path c:\DSProject. 

Build the project.

Browse to http://localhost/DSProject and, if you have enabled directory browsing, you should see the ISAPI dll.  Click it.  You should see a page like this:

The following a wizard generated line of code provide the default content:

At this point it looks like our ISAPI dll is properly configured.  Now I can use the Data Explorer to test connectivity.

Connect with Data Explorer

I prefer to use the stand alone DataExplore.exe when testing connections rather than the RAD studio Data Explorer view, just in case there is a connection problem that causes the client to become unresponsive. 

Start DataExplorer.exe.  Right click the DataSnap node, choose add connection.  Enter “NewConnection”.  Click OK.

Expand the DataSnap node, right click “New Connection” and select “Modify Connection”.

Set Protocol to “http”, Host to “localhost”, Port to “80” and Path to “DsProject/Project1.dll”.

Click “Test Connection”.   Click OK. Click OK. 

Expand the NewConnection/Procedures node to see that EchoString is a server method.

To test, right click on the “EchoString” node and choose "View Parameters". Select the "Value" parameter and enter some text for the "Value" property. Right click and choose "Execute" (or click the the  image button in the upper left of the view parameters window).  

At this point I’ve created a server, configured it to run under IIS, and connected to it with DataExplorer.   The new DataSnap 2010 HTTP client features will need to be covered in another post.

I have two additional topics to cover.  First is this ancestor issue I mentioned near the beginning of this post.  Finally, I will add a few words about debugging.

Ancestors and DataModules

This example used TPersistent as the ancestor of our server method class.   The other choices, in the wizard, are TDataModule and TDSServerModule.  Use TDataModule when you want to use components in your server methods.  Use TDSServerModule when you want the equivalent of TRemoteDataModule.

When using TDataModule or TDSServerModule, there is an important requirement that only affects WebBroker applications.  Be sure that the there is only one module created during startup.  Use Project/View Source… to see this code.  The only module created here should be the WebModule. 

The project source should look like this:

Something like this will result in an exception with the message “Only one data module per application”.

ISAPI Debugging

In case your ISAPI dll isn’t working properly because of this or other issues, here is how I configure my project for debugging.

In project options, set Host application to the location of w3wp.exe and the Parameters to “-debug”.

You will need to stop IIS before debugging.  Use the IIS manager or [c:/]net stop w3svc.

When you run the application, you should see a prompt like this:

When you stop debugging, w3wp.exe will be shut down.   When you are done working on your project, restore IIS with [c:/]net start w3svc.

Share This | Email this page to a friend

This client has the same functionality as the Delphi client described in this post: DataSnap Server Method Stream Parameters.  Here is a screen shot of the two clients running against the same Delphi sample server.

Download the Delphi sample server (and Delphi sample client) here: http://cc.codegear.com/item/26854.   For introductory information about the difference between Delphi and Delphi Prism DataSnap clients see this post: Call DataSnap Server Methods with Delphi Prism.

Stream Parameter Types

This table shows the parameter types and return types in the stream samples. The columns under “Server Parameter” describe the parameter or return type in the Delphi DataSnap servers methods. The “Delphi Type” column shows the corresponding type used in the Delphi client. The “Delphi Prism Type” column shows type used in the Delphi Prism client.

Code Samples

The following code samples show the differences between calling server methods with DbExpress in Delphi compared to ADO.NET in Delphi Prism.

function TTestStream.Echo(I: TStream): TStream;

function TTestStreamClient.Echo(I: TStream): TStream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand;
    FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FEchoCommand.Text := 'TTestStream.Echo';
    FEchoCommand.Prepare;
  end;
  FEchoCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  FEchoCommand.ExecuteUpdate;
  Result := FEchoCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

function TTestStreamClient.Echo(I: System.IO.Stream): System.IO.Stream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand as TAdoDbxCommand;
    FEchoCommand.CommandType := System.Data.CommandType.StoredProcedure;
    FEchoCommand.CommandText := 'TTestStream.Echo';
    FEchoCommand.Prepare;
  end;
  FEchoCommand.Parameters[0].Value := I;
  FEchoCommand.ExecuteNonQuery;
  Result := FEchoCommand.Parameters[1].Value as System.IO.Stream;
end;

procedure TTestStreamValue.Swap(I: TDBXStreamValue; J: TDBXStreamValue);

procedure TTestStreamValueClient.Swap(var I: TStream; var J: TStream);
begin
  if FSwapCommand = nil then
  begin
    FSwapCommand := FDBXConnection.CreateCommand;
    FSwapCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FSwapCommand.Text := 'TTestStreamValue.Swap';
    FSwapCommand.Prepare;
  end;
  if I = nil then
    FSwapCommand.Parameters[0].Value.SetNull
  else
    FSwapCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  if J = nil then
    FSwapCommand.Parameters[1].Value.SetNull
  else
    FSwapCommand.Parameters[1].Value.SetStream(J,  FInstanceOwner);
  FSwapCommand.ExecuteUpdate;
  if FSwapCommand.Parameters[0].Value.IsNull then
    I := nil
  else
    I := FSwapCommand.Parameters[0].Value.GetStream(FInstanceOwner);
  if FSwapCommand.Parameters[1].Value.IsNull then
    J := nil
  else
    J := FSwapCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

procedure TTestStreamValueClient.Swap(var I: System.IO.Stream; var J: System.IO.Stream);
begin
  if FSwapCommand = nil then
  begin
    FSwapCommand := FDBXConnection.CreateCommand as TAdoDbxCommand;
    FSwapCommand.CommandType := System.Data.CommandType.StoredProcedure;
    FSwapCommand.CommandText := 'TTestStreamValue.Swap';
    FSwapCommand.Prepare;
  end;
  if I = nil then
    FSwapCommand.Parameters[0].Value := DbNull.Value
  else
    FSwapCommand.Parameters[0].Value := I;
  if J = nil then
    FSwapCommand.Parameters[1].Value := DbNull.Value
  else
    FSwapCommand.Parameters[1].Value := J;
  FSwapCommand.ExecuteNonQuery;
  if FSwapCommand.Parameters[0].Value = DBNull.Value then
    I := nil
  else
    I := FSwapCommand.Parameters[0].Value as System.IO.Stream;
  if FSwapCommand.Parameters[1].Value = DBNull.Value then
    J := nil
  else
    J := FSwapCommand.Parameters[1].Value as System.IO.Stream;
end;

That’s all for now.  A post on table parameter types is coming soon. 

Share This | Email this page to a friend

See my earlier posts on “Basic” and “Basic DBXValue” types.   I’ve yet to post about TDBXConnection, TDBXConnectionValue, TDBXReader, TParams, and TDataSet.  However, TDataSet is demonstrated in the sample projects.

The following table summarizes differences between TStream and TDBXStreamValue types:

Supports null values

The TDBXStreamValue type has an IsNull property and a SetNull method.   Use this type instead of TStream a parameter value can be null/nil, in some cases.

Declaration

The var and out keywords can’t be used to specify the parameter direction of a TDBXStreamValue parameter.  The direction is always in/out. A TDBXStreamValue type can’t be used as a function result.

Proxy Generator

The RAD Studio 2007 client proxy generator does not work properly for server methods with TDBXStreamValue parameters. So you will need to hand code the client code or correct the generated proxy. The sample client has hand corrected proxy methods that look like this.

function TTestStreamValueClient.Echo(var I: TStream): TStream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand;
    FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FEchoCommand.Text := 'TTestStreamValue.Echo';
    FEchoCommand.Prepare;
  end;
  if I = nil then
    FEchoCommand.Parameters[0].Value.SetNull
  else
    FEchoCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  FEchoCommand.ExecuteUpdate;
  if FEchoCommand.Parameters[0].Value.IsNull then
    I := nil
  else
    I := FEchoCommand.Parameters[0].Value.GetStream(FInstanceOwner);
  Result := FEchoCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

This client method works with a server method declared as follows:

function Echo(I: TDBXStreamValue): TStream;

Calling a server method with a TDBXStreamValue parameter is the same as calling a server method with an TStream parameter, except that you can use SetNull and IsNull methods to work with null values.

For example, compare the following server method declaration and client method implementation to the previous example:

function Echo(I: TStream): TStream; 

function TTestStreamClient.Echo(I: TStream): TStream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand;
    FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FEchoCommand.Text := 'TTestStream.Echo';
    FEchoCommand.Prepare;
  end;
  FEchoCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  FEchoCommand.ExecuteUpdate;
  Result := FEchoCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

Accessing Values

The GetStream and SetStream methods have an InstanceOwner parameter.  Passing True indicates that DBX owns the stream and will free it.  Passing False indicates that the caller owns the stream.  To control how the generated proxy classes call SetStream and GetStream, there is an AInstanceOwner parameter on the proxy class constructor:

constructor TTestStreamClient.Create(ADBXConnection: TDBXConnection; AInstanceOwner: Boolean);

The other constructor is equivalent to passing AInstanceOwner as True.

constructor TTestStreamClient.Create(ADBXConnection: TDBXConnection);

Sample Client And Server Applications

The sample server has a few simple server methods for passing values (including null).

  {$METHODINFO ON}
  TTestCollection = class(TComponent)
  strict protected
    procedure LogMessage(const AMessage: string);
  public
    // Server method to get the parameter type names
    procedure GetTypeNames(I: T; ADeclaredName, AActualName: TDBXStringValue);
  end;
  {$METHODINFO OFF}

  TTestStream = class(TTestCollection)
  public
    function Echo(I: TStream): TStream;
    procedure Copy(I: TStream; out J: TStream);
    procedure Swap(var I: TStream; var J: TStream);
  end;

  TTestStreamValue = class(TTestCollection)
  public
    function Echo(I: TDBXStreamValue): TStream;
    procedure Copy(I: TDBXStreamValue; J: TDBXStreamValue);
    procedure Swap(I: TDBXStreamValue; J: TDBXStreamValue);
    function IsNull(I: TDBXStreamValue): Boolean;
    procedure SetNull(I: TDBXStreamValue);
  end;

The sample client tests the server methods by calling them with sample values and verifying the results (e.g; comparing streams). TMemoryStream is used to pass short streams and TFileStream to pass long streams.  Here is a screen shot of the running server and client:

The following table shows the parameter types and return types demonstrated in the sample client and server:

Stream Usage

Check  “Log Stream Usage” to show TStream sizes, type names, creates, destroys, and reads.  The results from 4 different test cases are displayed after “Call Server Methods” is clicked. 

The screen shot below shows the result from a test case with longer streams.  I’ve added highlighting to illustrate these points:

1. When the server reads a longer stream passed from the client, round trips are made to the client.  This makes it possible to send very large streams to the server without consuming lots of memory.
2. When the client reads a longer stream passed from the server, round trips are made to the server.  This makes it possible to return very large streams to the client without consuming lots of memory.
3. The TStream objects that represent longer client and server streams have a Size of –1, meaning the size is unknown.  Rely on the return value of TStream.Read to detect the end of the stream.  Also note that some DBX streams such as TDBXStreamReaderStream do not fully support Seek.

That’s all for now.

Share This | Email this page to a friend

There are two new samples that go along with this post: http://cc.embarcadero.com/item/26806 and http://cc.embarcadero.com/item/26805

The first sample is a Delphi Prism client that demonstrates "Basic" types.  This client has nearly the same functionality as the Delphi client described in this post: DataSnap Server Methods Parameters.  The difference is that the Delphi Prism client isn’t able to call server methods with OleVariant parameter types.  The Delphi client is shown on the left and the Delphi Prism client on the right:

The second sample is a Delphi Prism client that demonstrates "Basic DBXValue" types.  This client has the same functionality as the Delphi client described in this post: DataSnap Server Method DBXValue Parameters.  The Delphi client is shown on the left and the Delphi Prism client on the right:

The Delphi Prism clients use the same sample servers as the Delphi clients.  Download the Delphi sample servers (and Delphi sample clients) here: http://cc.codegear.com/item/26702, http://cc.embarcadero.com/item/26734.

The following table summarizes the major differences between the Delphi and Delphi Prism sample clients:

Connectivity

The Delphi Prism client uses the DataSnap ADO.NET provider rather than native DbExpress.  Here are some code samples to show differences between calling DataSnap server methods with DbExpress in Delphi vs. ADO.NET in Delphi Prism.

  TTestIntegerClient = class
  private
    FDBXConnection: TDBXConnection;
    FInstanceOwner: Boolean;
    FEchoCommand: TDBXCommand;
    FCopyCommand: TDBXCommand;
    FSwapCommand: TDBXCommand;
  public
    constructor Create(ADBXConnection: TDBXConnection); overload;
    constructor Create(ADBXConnection: TDBXConnection; AInstanceOwner: Boolean); overload;
    destructor Destroy; override;
    function Echo(I: Integer): Integer;
    procedure Copy(I: Integer; out J: Integer);
    procedure Swap(var I: Integer; var J: Integer);
  end;

  TTestIntegerClient = class
  private
    FDBXConnection: TAdoDbxConnection;
    FInstanceOwner: Boolean;
    FEchoCommand: TAdoDbxCommand;
    FCopyCommand: TAdoDbxCommand;
    FSwapCommand: TAdoDbxCommand;
  protected
    procedure Dispose(ADisposing: Boolean); virtual;
  public
    constructor Create(ADBXConnection: TAdoDbxConnection);
    constructor Create(ADBXConnection: TAdoDbxConnection; AInstanceOwner: Boolean);
    procedure Dispose; virtual;
    function Echo(I: Integer): Integer;
    procedure Copy(I: Integer; out J: Integer);
    procedure Swap(var I: Integer; var J: Integer);
  end;

procedure TTestIntegerClient.Swap(var I: Integer; var J: Integer);
begin
  if FSwapCommand = nil then
  begin
    FSwapCommand := FDBXConnection.CreateCommand;
    FSwapCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FSwapCommand.Text := 'TTestInteger.Swap';
    FSwapCommand.Prepare;
  end;
  FSwapCommand.Parameters[0].Value.SetInt32(I);
  FSwapCommand.Parameters[1].Value.SetInt32(J);
  FSwapCommand.ExecuteUpdate;
  I := FSwapCommand.Parameters[0].Value.GetInt32;
  J := FSwapCommand.Parameters[1].Value.GetInt32;
end;

procedure TTestIntegerClient.Swap(var I: Integer; var J: Integer);
begin
  if FSwapCommand = nil then
  begin
    FSwapCommand := FDBXConnection.CreateCommand as TAdoDbxCommand;
    FSwapCommand.CommandType := System.Data.CommandType.StoredProcedure;
    FSwapCommand.CommandText := 'TTestInteger.Swap';
    FSwapCommand.Prepare;
  end;
  FSwapCommand.Parameters[0].Value := I;
  FSwapCommand.Parameters[1].Value := J;
  FSwapCommand.ExecuteNonQuery;
  I := FSwapCommand.Parameters[0].Value as Integer;
  J := FSwapCommand.Parameters[1].Value as Integer;
end;

Proxy Generator

Delphi Prism does not have a DataSnap client proxy generator like the one in Delphi.  The preceding Delphi code sample was generated with the proxy generator; the Delphi Prism code sample was hand written.

UI Framework

The Delphi Prism sample clients are WinForm applications.  DataSnap clients may be implemented in other application types supported by Delphi Prism, such as ASP.NET. 

Parameter Types

The following table shows the parameter types and return types demonstrated in the “Basic” types samples.   The columns under “Server Parameter” describe the parameter or return type in the Delphi DataSnap server’s methods.  The “Delphi Type” column shows the corresponding type used in the Delphi client.  The “Delphi Prism Type” show the corresponding type used in the Delphi Prism client.

The following table shows the parameter types and return types demonstrated in the “Basic DBXValue” types samples:

Language Compatability

Syntax

Delphi Prism projects uses the Oxygene language.

In these samples, there are a few syntax differences between Oxygene .pas files and Delphi .pas files including  keyword (e.g.; unit vs. namespace, var and out in method calls) and a delimiter (e.g.; Oxygene requires  ‘;’ and ‘@’ in places that Delphi doesn’t).  Diff the like named .pas files for details.

Delphi Prism has some project options that enable the Oxygene compiler to accept more Delphi language conventions.  Choose “Project/Project properties…”  The one I’ve checked for these samples is “Allow ‘Create’ constructor calls’.  This option enables compilation of the following line:

LTest := TTestBooleanClient.Create(DBXConnection)

Otherwise, the code would need new instead of Create:

LTest := new TTestBooleanClient.(DBXConnection).

Destroy vs. Dispose

In the Delphi Prism samples, Dispose is called in place of Destroy in the Delphi samples.   Calling Dispose doesn’t free the object but tells the object to release unmanaged resources (like a tcp/ip connection). 

SysUtils.Format vs. String.Format

In the Delphi Prism samples, String.Format is called in place of Format in the Delphi samples:

LogTestMessage(string.Format(’{0:s} {1:s}’, [FClassName + '.' + LMethodName, LDeclaredType]));

in place of

LogTestMessage(Format(’%0:s (%1:s)’, [FClassName + '.' + LMethodName, LDeclaredType]));

That’s all for now.  I (continue to) plan on covering collection types in my next post.

Share This | Email this page to a friend

The following table summarizes differences between "Basic" and "Basic DBXValue" types:

�

Supports null values

Support for null values is needed, for example, when a server method needs to pass values that come from a database column that allows NULL.    All DBXValue types have an IsNull property and a SetNull method.

Declaration

The var and out keywords can’t be used to specify the parameter direction of a DBXValue parameter.  The direction is always in/out.   A DBXValue type can’t be used as a function result.

Proxy Generator

The RAD Studio 2007 client proxy generator does not work properly for server methods with DBXValue parameters.  So you will need to hand code.   The sample client has code like this to call a server method:

// Non-generic version of TestSetNull
procedure TCallTestMethods.TestSetNullInt32(AConnection: TDBXConnection; I: Int32);
const
  LMethodName = 'TTestDBXInt32Value.SetNull';
var
  LIsNull: Boolean;
  LDBXCommand: TDBXCommand;
begin
  LDBXCommand := AConnection.CreateCommand;
  try
    try
      LDBXCommand.CommandType := TDBXCommandTypes.DSServerMethod;
      LDBXCommand.Text := LMethodName;
      LDBXCommand.Prepare;
      LDBXCommand.Parameters[0].Value.SetInt32(I);
      LDBXCommand.ExecuteUpdate;
      LIsNull := LDBXCommand.Parameters[0].Value.IsNull;
      LogTestResult(LMethodName, LIsNull);
    except
      on E: Exception do
      LogTestException(LMethodName, E);
    end;
  finally
    LDBXCommand.Free;
  end;
end;

Calling a server method with a TDBXInt32Value parameter is the same as calling a server method with an Int32 parameter, except that you can use SetNull and IsNull methods to work with null values.  

Accessing Values

The following table shows the methods that are used to access a non-null value from the different DBXValue types   A mismatched call, such as GetBcd on TDBXStringValue, will raise an exception. 

�

String Value Types

Of the five DBXValue types that represent strings, you need only use TDBXAnsCharsValue to pass AnsiString values and TDBXWideCharsValue to pass UnicodeString/string values. The following table shows that these two types are always passed to server methods even if the method is declared with one of the other string types.

Sample Client And Server Applications

The sample server has a few simple server methods for passing values (including null), and two informational server methods.  In order to support various DBXValue types, I’ve implemented a generic server method base class:

{$METHODINFO ON}
  TTestBasicDBXValueType = class(TComponent)
  strict protected
    function EqualValues(I: TValue; J: TValue): Boolean; virtual;
    function GetValue(I: T): TValue; virtual; abstract;
    procedure SetValue(I: T; Value: TValue); virtual; abstract;
  public
    // Server methods to pass values (including null)
    function IsEqual(I: T; J: T): Boolean;
    function Echo(I: T): TValue;
    procedure Swap(I: T; J: T);
    function IsNull(I: T): Boolean;
    procedure SetNull(I: T);
    // Server method to get the DBXValue parameter type names
    procedure GetTypeNames(I: T; ADeclaredName, AActualName: TDBXStringValue);
    // Server method to try DBXValue methods like GetInt32 and SetInt32
    function TryGetAndSet(I: T): TDataSet;
  end;
{$METHODINFO OFF}

Then I’ve used TTestBasicDBXValueType to declare and implement server methods classes for a variety of DBXValue types, such as TDBXInt32Value, TTestDBXDateValue , etc.

  TTestDBXInt32Value = class(TTestBasicDBXValueType)
  strict protected
    function GetValue(I: TDBXInt32Value): Int32; override;
    procedure SetValue(I: TDBXInt32Value; Value: Int32); override;
  end;

  TTestDBXDateValue = class(TTestBasicDBXValueType)
  strict protected
    function GetValue(I: TDBXDateValue): TDBXDate; override;
    procedure SetValue(I: TDBXDateValue; Value: TDBXDate); override;
  end;

Consult the sample server to see how I’ve implemented the "plumbing" to make these classes callable by a DataSnap client. As in the “Basic” types sample server, the implementation is unconventional because the TDSServerClass component is not used.

The sample client tests the generated methods by calling them with sample values and verifying the results. Consult the sample for implementation details. Here is screen shot of the running server and client:

The following table shows the parameter types and return types demonstrated in the sample client and server:

That’s all for now.  I plan on covering the collection types in my next post.

Share This | Email this page to a friend

DataSnap server methods support a variety of parameter and return types. The following list shows the types grouped into my own categories. 

This post is about "Basic" types.  The sample client and server projects that go with this post can be downloaded here: http://cc.codegear.com/item/26702

Getting Started with Delphi DataSnap 2009 uses the following function as an example of a server method:

function TDSServerModule1.Echo(s: string): string;
begin
 Result := 'Delphi DataSnap 2009 is echoing ' + s + ' ....' + s;
end;

The proxy generator generates the following code to call this method:

function TDSServerModule1Client.Echo(s: string): string;
begin
  if FEchoCommand = nil then
   begin
     FEchoCommand := FDBXConnection.CreateCommand;
     FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
     FEchoCommand.Text := 'TDSServerModule1.Echo';
     FEchoCommand.Prepare;
   end;
   FEchoCommand.Parameters[0].Value.SetWideString(s);
   FEchoCommand.ExecuteUpdate;
   Result := FEchoCommand.Parameters[1].Value.GetWideString;
end;

I wanted my sample server and client to work like the sample in the article, with simple server methods and  generated proxy in the client.  In addition, I wanted to support various types so started with this generic server method implementation:

{$METHODINFO ON}
 TTestBasicType = class(TComponent)
     function Echo(I: T): T;
 end;
{$METHODINFO OFF}

 function TTestBasicType.Echo(I: T): T;
 begin
   Result := I;
 end;

The I used TTestBasicType used to declare and implement "Echo" methods for a variety of types, such as string, boolean, and double:

TTestString = class(TTestBasicType<string>))
end;

TTestBoolean = class(TTestBasicType<Boolean>)
end; 

TTestDouble = class(TTestBasicType<Double>))
end;

To test parameters directions, I expanded the generic class with var and out parmeters:

{$METHODINFO ON}
TTestBasicType = class(TComponent)
  function Echo(I: T): T;
  procedure Copy(I: T; out J: T);
  procedure Swap(var I: T; var J: T);
end;
{$METHODINFO OFF}

Consult the sample server to see how I’ve implemented the "plumbing" to make these classes callable by a DataSnap client. The implementation is unconventional because the TDSServerClass component is not used.

The sample VCL client is built starting with a TSQLConnection component. After setting the port and host name, I right clicked on the TSQLConnection and selected "Generate DataSnap client classes" to generate a client proxy:

In the generated code, there is a "Client" class for every one of the server classes. For example, TTestBooleanClient calls the TTestBoolean class on the server:

TTestBooleanClient = class
private
  FDBXConnection: TDBXConnection;
  FInstanceOwner: Boolean;
  FEchoCommand: TDBXCommand;
  FCopyCommand: TDBXCommand;
  FSwapCommand: TDBXCommand;
public
  constructor Create(ADBXConnection: TDBXConnection);overload;
  constructor Create(ADBXConnection: TDBXConnection; AInstanceOwner: Boolean); overload;
  destructor Destroy; override;
  function Echo(I: Boolean): Boolean;
  procedure Copy(I: Boolean; out J: Boolean);
  procedure Swap(var I: Boolean; var J: Boolean);
end;

Here is the implementation of TTestBooleanClient.Echo.  Consult the sample code to see the complete proxy implementation.  

function TTestBooleanClient.Echo(I: Boolean): Boolean;
begin
 if FEchoCommand = nil then
 begin FEchoCommand := FDBXConnection.CreateCommand;
   FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
   FEchoCommand.Text := 'TTestBoolean.Echo';
   FEchoCommand.Prepare;
 end; FEchoCommand.Parameters[0].Value.SetBoolean(I);
 FEchoCommand.ExecuteUpdate;
 Result := FEchoCommand.Parameters[1].Value.GetBoolean;
end;

The sample client tests the generated methods by calling them with sample values and verifying the results. Consult the sample for implementation details.

Here is screen shot of the running server and client:

The following table shows the parameter types and return types demonstrated in the sample client and server:

There are some Delphi types that you might expect to see in this list such as Byte and Cardinal. DataSnap currently doesn’t support these two nor LongWord, ShortInt, Word, TSQLTimeStamp, and TBcd. Support for var and out strings is coming (a workaround/alternative is to use TDBXStringValue in place of var String and TDBXAnsiStringValue in place of var AnsiString).

Thats all for now. I plan to cover more types in the future.

Share This | Email this page to a friend