Well .. Be-Delphi is an initiative from Filip Lagrou and his goal is to promote the use of Delphi by organizing events, consultancy, training, component- and tool reseller and custom development. Last year he organized the very first Be-Delphi Developer Event, and this year it was time for Be-Delphi 2.0. Last year I gave a presentation about Live Bindings in Delphi XE2 ... but this year I decided to talk about something else ... something I'm quite passionate about ...

UI <>UX and why you should care about that

For those of you who worked with me in the past, it wont be a big surprise, but I've always been a perfectionist when the User Experience is concerned. I'm probably one of those Delphi developers who can take of his Developer hat and look at an application or screen with a Common User hat. This has always allowed me to see things other developers don't notice, find bugs others don't, find holes in workflows ... and yes ... notice that buttons placed one pixel lower than all other buttons.

Many developers think about those things as a non-issue. Who cares about the pixel ... it works. And if it's only a pixel ... then they might be right. Personally I'm the developer who will try to fix those things. It probably takes longer to say 'Who cares about that pixel' than actually moving the button up one pixel anyway. I have also noticed that a lot of developers are big fans of their mouse. For most of them using keyboard shortcuts is just a wast of time ... although plenty of them know the shortcuts for Copy and Paste way too well :-)

So ... to make a long story short ... I decided not to show any code, but instead focus on the whole User Experience thing. Since I'm quite passionate about that ... it can also get a little emotional, and I think I put all of those emotions in my presentation. The presentation itself is available on SlideShare and I have embedded it into this post. Of course ... you will only get the slides and you will miss the emotions, stories and anecdotes I uses in my presentation.

UI is not the same as UX and why you should care about that (Be-Delphi 2.0) from Stefaan Lesage

During the day I also shot a few pictures which I have uploaded to my Flickr stream. Feel free to go check them out in the Be-Delphi 2.0 set.

Questions, Comments, Suggestions and Feedback

If you attended my session at Be-Delphi 2.0 and have any additional questions, comments, suggestions or feedback ... please feel free to get in touch. And if you encounter some nice examples of bad or good User Experience you can always take a picture and send it to me. Who knows ... I might add it to a revised version of this presentation.

Yesterday was Be-Delph, and I was invited to give a talk on the new LiveBindings in Delphi XE2. Me and a colleague of mine decided to drive up there together, which should have given me some time to relax. Sadly it didn't and I was kinda nervous.

Once we got welcomed by Pascal Lagrou and Bruno Fierens from TMS Software, had a coffee or two and we were ready for the sessions. My session on LiveBindings in Delphi XE2 was only in the afternoon, so I still had some time to build up additional stress. In the end everything went quite well. I was nervous in the beginning, but once I could dive into familiar territory (the Delphi XE2 IDE) everything went a lot smoother.

I would personally want to thank everyone who made this even possible, including Filip Lagrou, Bruno Fierens, Thierry Laborde, Brian Long, Jason Vokes and Bob Swart, and everyone who helped behind the scenes. Also a big thank you for the Be-Delph sponsors TMS Software, Embarcadero, Dr Bob, RemObjects, Fast Report, Expert Team, C-Quel Software Solutions, Raize Software, Devart, Blaise Pascal, and all sponsors who supplied us with prizes. In case I forgot some, you can find the full list of sponsors right here.

I hope everyone enjoyed Be-Delphi and hope we will all meet up at the next Be-Delphi. For those of you who missed Be-Delphi, I have uploaded my presentation and the corresponding White Paper document :

Presentation

BEDelphi - LiveBindings in Delphi XE2 - Devia

View more presentations from Stefaan Lesage

The White Paper

Be Delphi Live Bindings

Unlike building a Mac version of your Delphi XE2 FireMonkey application, creating an iOS application using Delphi XE2 and FireMonkey has some prerequisites.

XCode

First of all you will need to install XCode on your Mac. This can easily be done by downloading XCode from the Mac AppStore, or through the developer portal website. For the iOS versions of your Delphi XE 2 FireMonkey apps you will have to compile them using XCode. From within XCode you will be able to debug those applications and deploy them on a physical device.

FreePascal and FireMonkey

In order to build your Delphi XE2 FireMonkey applications for iOS devices you will need the FreePascal compiler and the necessary FireMonkey files. Luckily this can be found in your Delphi XE2 installation folder. Simply copy the Disk Image File (dmg) over to your mac and run the installation.

Apple Developer Program

If you want to deploy your applications to a physical iOS device, you will need to register for the iOS Developer Program which will cost you about $99 or 79 € per year. You will also have to be part of that iOS Developer program if you ever want to publish you Delphi XE2 FireMonkey apps to the iOS AppStore.

Creating a test iOS application using Delphi XE2 and FireMonkey

Creating a new FireMonkey iOS application

Unlink Delphi XE2 FireMonkey applications for the Mac, FireMonkey iOS applications are a special type of Delphi XE2 project. So you will have to create a new application using the corresponding menu. In our example we will create a very simple application ... noting special ... just to show you everything works nicely.

Exporting the Delphi XE2 FireMonkey Application to XCode

As mentioned before ... you currently still need XCode and the FreePascal compiler to Build your iOS application. Due to some limitations in FreePascal your Delphi XE2 FireMonkey code will need to be modified slightly so it can be compiled (one example is the Dotted namespaces which doesn't seem to be working under FreePascal). In order to do this a little utility can be used called dprtoxcode.exe

The Tutorial shows you how you can add this little utility to your Delphi XE2 tools menu so it is easier to use.

Building & Testing your application using XCode

Once everything is ready, you can open the XCode version of your Delphi XE2 FireMonkey project, build it and run it in the Simulator to test it if necessary. From here you could also deploy it to a physical iOS device or the iOS AppStore, but for that you will need to enroll in the iOS Developer Program.

In our Video Tutorial we will be building a small sample application to show you how the process is supposed to be done. It isn't a full blown iOS application though, but just a little example.

Final Words

Well ... this tutorial should have shown you the basics of setting everything up and even showed you how to create your first iOS application. If you have any comments or suggestions ... feel free to post them here as a comment or contact us.

Meanwhile ... have fun with Delphi XE2 and FireMonkey ... and if you want to learn more about Delphi XE2, make sure you also check the Delphi XE2 page or RAD Studio XE2 page on the Embarcadero Website.

If you want, you can also have a look at the video on YouTube. You should be able to find an HD version right here

Well ... now that Delphi XE2 is finally available, the testers are no longer under NDA and I can safely say you can create Mac and even iOS applications using Delphi XE2 and FireMonkey. If you want to know more about FireMonkey, feel free to have a look at the information available on the Embarcadero website, or even have a look at this very interesting post about FireMonkey by Andrano Lanusse (Embarcadero Technical Lead Evangelist for Latin America & Caribeean). Today I won't be going into a lot of detail about FireMonkey or what you can do with FireMonkey though ...

Setting it up

If you were at the World Tour in Brussels, you might have seen and heard Pawel Glowacki talk about using PAServer to deploy and debug Delphi XE2 FireMonkey applications on the Mac. If you have a Mac and already have Delphi XE2 you might be wondering what he was talking about and how you can set up your machines to actually run Delphi XE2 FireMonkey applications on your Mac and still develop and debug them on your Windows Machine. Well ... it actually is a lot easier than you would think.

A Screencast

For those of you who want to get started right away, but are wondering how you should configure everything, I prepared a little Screencast. This Screencast guides you through the setup and configuration and even shows you how to develop / deploy and Debug a simple 'Hello World' application on your Mac which was developed using Delphi XE2 and FireMonkey on Windows. The Video is Hosted on YouTube and I have embedded it on this page. It might be interesting to look at the HD version in FullScreen Mode on YouTube thought ...

Since for some strange reason I couldn't fit everything in a single post, I had to split it up, so this is the rest of it

The TdvStringSetting class

The explanation

Basically the TdvSetting provides us with a skeleton we can use for our new Setting descendants. I ended up with a TdvStringSetting, TdvIntegerSetting, TdvBooleanSetting and quite a few others, but lets start with the TdvStringSetting first.

The Code

  TdvStringSetting = class( TdvSetting )
  private
    function GetDefaultValueAsString: String;
  protected
    function GetAsBoolean: Boolean; override;
    function GetAsDateTime: TDateTime; override;
    function GetAsFloat: Double; override;
    function GetAsInteger: Longint; override;
    function GetAsString: string; override;
    function GetAsVariant: Variant; override;

    function GetValue(var Value: string): Boolean;

    procedure SetAsBoolean(const Value: Boolean); override;
    procedure SetAsDateTime(const Value: TDateTime); override;
    procedure SetAsFloat(const Value: Double); override;
    procedure SetAsInteger(const Value: Longint); override;
    procedure SetAsString(const aValue: string); override;
    procedure SetVarValue(const aValue: Variant); override;
  public
    procedure SaveToRegIni  ( aRegIni : TRegistryIniFile; const aSection : String ); override;
    procedure LoadFromRegIni( aRegIni : TRegistryIniFile; const aSection : String ); override;

    property DefaultValue  : String       read  GetDefaultValueAsString;
    property Value         : string       read  GetAsString
                                          write SetAsString;
  end;

...

{ TdvStringSetting }

function TdvStringSetting.GetAsBoolean: Boolean;
var
  S: string;
begin
  S := GetAsString;
  Result := (Length(S) > 0) and (S[1] in ['T', 't', 'Y', 'y']);
end;

function TdvStringSetting.GetAsDateTime: TDateTime;
begin
  Result := StrToDateTime(GetAsString);
end;

function TdvStringSetting.GetAsFloat: Double;
begin
  Result := StrToFloat(GetAsString);
end;

function TdvStringSetting.GetAsInteger: Longint;
begin
  Result := StrToInt(GetAsString);
end;

function TdvStringSetting.GetAsString: string;
begin
  if not GetValue(Result) then Result := '';
end;

function TdvStringSetting.GetAsVariant: Variant;
var
  S: string;
begin
  if GetValue(S) then Result := S else Result := Null;
end;

function TdvStringSetting.GetDefaultValueAsString: String;
begin
  Result := FDefaultValue;
end;

function TdvStringSetting.GetValue(var Value: string): Boolean;
begin
  Value  := FValue;
  Result := True;
end;

procedure TdvStringSetting.LoadFromRegIni(aRegIni: TRegistryIniFile;
  const aSection: String);
begin
  inherited LoadFromRegIni( aRegIni, aSection );

  Value := aRegIni.ReadString( aSection, Identifier, DefaultValue );
end;

procedure TdvStringSetting.SaveToRegIni(aRegIni: TRegistryIniFile;
  const aSection: String);
begin
  inherited SaveToRegIni( aRegIni, aSection );

  aRegIni.WriteString( aSection, Identifier, Value );
end;

procedure TdvStringSetting.SetAsBoolean(const Value: Boolean);
const
  Values: array[Boolean] of string[1] = ('F', 'T');
begin
  SetAsString(Values[Value]);
end;

procedure TdvStringSetting.SetAsDateTime(const Value: TDateTime);
begin
  SetAsString(DateTimeToStr(Value));
end;

procedure TdvStringSetting.SetAsFloat(const Value: Double);
begin
  SetAsString(FloatToStr(Value));
end;

procedure TdvStringSetting.SetAsInteger(const Value: Integer);
begin
  SetAsString(IntToStr(Value));
end;

procedure TdvStringSetting.SetAsString(const aValue: string);
begin
  FValue := aValue;
end;

procedure TdvStringSetting.SetVarValue(const aValue: Variant);
begin
  SetAsString(aValue);
end;

What does it do ?

Since we had the skeleton of the TdvSetting in place, the only thing we needed to do was to override the necessary methods and implement our own features. As you can see, we added approximately the same code as can be found in the TStringField in the VCL.

The only additional code is the implementation of the SaveToRegIni and LoadFromRegIni methods. These methods will actually load and save the value of the Setting to the Registry. Additionally when loading the value we will be using the Default value if the setting can't be found in the regsitry. The Section where we will read / write the value can be supplied to the method and we will be using the identifier (name) of the setting as the key

Creating the TdvSettings class

The explanation

Well, now that we can make different type of Setting objects, we also need some kind of container to hold them. For example our application might have quite a few settings : PrintInColor, CheckForUpdates, AutoConnect, ... but we will need some way to access them. As mentioned before I created the TdvSettings class as a simple TObjectList. It will hold a reference to the individual TdvSetting objects and we will be able to access them

The Code

  TdvSettings = class( TObjectList )
  private
    FRootKey: String;
  protected
    procedure CreateSettings; virtual;

    function GetItems(Index: Integer): TdvSetting;
    procedure SetItems(Index: Integer; ASetting: TdvSetting);
  public
    constructor Create( const aRootKey : String );

    function Add(ASetting: TdvSetting): Integer;
    function Extract(Item: TdvSetting): TdvSetting;
    function Remove(ASetting: TdvSetting): Integer;
    function IndexOf(ASetting: TdvSetting): Integer;
    function First: TdvSetting;
    function Last: TdvSetting;
    function SettingByIdentifier( const aIdentifier : String ) : TdvSetting;

    procedure LoadFromRegistry;
    procedure SaveToRegistry;

    procedure Insert(Index: Integer; ASetting: TdvSetting);
    property Items[Index: Integer]: TdvSetting read GetItems write SetItems; default;
    property RootKey : String read FRootKey write FRootKey;
  end;

  ...

{ TdvSettings }

function TdvSettings.Add(ASetting: TdvSetting): Integer;
begin
  Result := inherited Add(ASetting);
end;

constructor TdvSettings.Create(const aRootKey: String);
begin
  inherited Create( True );
  FRootKey := aRootKey;
  CreateSettings;
  // Read the settings from the Registry once the Settings object list has
  // been initialised.
  LoadFromRegistry;
end;

procedure TdvSettings.CreateSettings;
begin

end;

function TdvSettings.Extract(Item: TdvSetting): TdvSetting;
begin
  Result := TdvSetting(inherited Extract(Item));
end;

function TdvSettings.First: TdvSetting;
begin
  Result := TdvSetting(inherited First);
end;

function TdvSettings.GetItems(Index: Integer): TdvSetting;
begin
  Result := TdvSetting(inherited Items[Index]);
end;

function TdvSettings.IndexOf(ASetting: TdvSetting): Integer;
begin
  Result := inherited IndexOf(aSetting);
end;

procedure TdvSettings.Insert(Index: Integer; ASetting: TdvSetting);
begin
  inherited Insert(Index, aSetting);
end;

function TdvSettings.Last: TdvSetting;
begin
  Result := TdvSetting(inherited Last);
end;

procedure TdvSettings.LoadFromRegistry;
var
  lIndex   : Integer;
  lSetting : TdvSetting;
  lRegIni  : TRegistryIniFile;
begin
  lRegIni := TRegistryIniFile.Create('');
  try
    for lIndex := 0 to Pred( Count ) do
    begin
      lSetting := Items[ lIndex ];
      lSetting.LoadFromRegIni( lRegIni, RootKey );
    end;
  finally
    FreeAndNil( lRegIni );
  end;
end;

function TdvSettings.Remove(ASetting: TdvSetting): Integer;
begin
  Result := inherited Remove(aSetting);
end;

procedure TdvSettings.SaveToRegistry;
var
  lIndex   : Integer;
  lSetting : TdvSetting;
  lRegIni  : TRegistryIniFile;
begin
  lRegIni := TRegistryIniFile.Create('');
  try
    for lIndex := 0 to Pred( Count ) do
    begin
      lSetting := Items[ lIndex ];
      lSetting.SaveToRegIni( lRegIni, RootKey );
    end;
  finally
    FreeAndNil( lRegIni );
  end;
end;

procedure TdvSettings.SetItems(Index: Integer; ASetting: TdvSetting);
begin
  inherited Items[Index] := aSetting;
end;

function TdvSettings.SettingByIdentifier(
  const aIdentifier: String): TdvSetting;
var
  lcv : Integer;
begin
  Result := Nil;

  for lcv := 0 to Pred( Count ) do
  begin
    if ( Items[ lcv ].Identifier = aIdentifier ) then
    begin
      Result := Items[ lcv ];
      Break;
    end;
  end;
end;

What does it do ?

Well, it is simply a container for a number of TdvSetting objects. It has some basic code which will allow us to access the individual TdvSetting objects using their index or their Identifier (name). We will be able to set the RootKey of the TdvSettings object and that is the base key which will be used when loading / storing the individual TdvSetting objects.

You willl notice that I added a CreateSettings method which is currently empty. The goal is to implement this in descendant classes. At the TdvSettings level we don't yet know which individual settings we will need, how they are called and what type they are ... Yet, I wanted to be able to create those settings from within the base class and once that is done read the settings if necessary.

In my TdvMyApplicationSettings I will override this method and add the necessary code to set up the individual TdvSetting objects I need for my applicaiton.

What's next ?

Currently we have a basic skeleton in place and we are able to continue from here. If you're up for a challenge, you might want to create your own TdvSetting descendants. I noticed I needed one for Integer values, DataTime values and Boolean values, so you could try to implement those.

As I mentioned at the end of the previous article, this isn't the only way, nor THE way to solve this problem, and I actually did try a few other approaches as well. It did take me a few iterations to get to this stage. For example, initial versions had the actual code for creating the TRegistryIniFile class inside the individual TdvSetting objects.

Quickly I noticed though that I had the exact same code in all my TdvSetting descendants LoadFromRegIni and SaveToRegIni methods so I started thinking again. I thought that constructing & destroying the TRegistryIniFile might be something I don't want to execute for the 20 individual application settings so I ended up refactoring the code to it's current status

Feedback

I'm quite sure the code could be simplified and maybe improved, and I do welcome all suggestions and feedback. So feel free to post all comments on this blog and I'll try to respond ASAP. Maybe your feedback will shape the next article in this series ...

So, basically we need a class / object which we can use to read and write some application settings from and to the Windows Registry. Sounds pretty straightforward ... but we did some additional thinking and found out that we might need to add some stuff in the future.

Basic Requirements of the code

Compatibility with Delphi 7

Although quite a few new features were added to the language in the last years, we won't be using them 'yet'. Our goal is that the code should compile / work under Delphi 7.

You may be asking yourselves "Who going though all that trouble for an old Delphi version ?", well I noticed that even today some of my clients still have older projects which get compiled in Delphi 7. In later articles I might show you how to do it using some newer techniques, but for now lets just stick with something that will compile under Delphi 7

Not limited to the Windows Registry

Although we will be writing the code based on using the Windows Registry to Load and Save our data. We want an easy way to adapt our code for some other things like storing the data in XML or an Ini file. After all, we don't know what the future will bring yet. We might be able to build applications for Windows Mobile, the Mac, iPhone or even iPad in the future (Would that be nice), and the Windows Registry might not be available on those devices.

For now we will focus on the Windows Registry, but as you notice it is a good idea to keep a few other possibilities ready. In the end, the only thing we care about is that we can store / load some settings. How or where these settings are stored isn't all that important, it just needs to get done !

Additional Things

So far, we know we will need something to hold a set of settings. We need to be able to load and save those settings. We will probably be supplying a name for each individual setting, maybe even a default value and a description. We need to be able to store Integers, Strings, but who knows even Passwords, Dates, ...

Lets get Coding !

... well almost ...

Well, ... actually before we start coding we could take a look at how some of these things get solved in the VCL. Of course, we could do all the coding ourselves, but it might be a good idea to let our new classes inherit from some existing classes. Since we need a list of things, you might want to take a look at the TList for example.

In my case, I knew I want to have a Setting which I will use to store Strings, one to store Integers and another one to store Booleans. Once I had those, I quickly noticed I wanted some others for DateTime values and quite a few other things as well. I actually ended up doing something quite similar to TField and TIntegerField, TStringField, ...

So, now that I know I will be using different types of Setting objects and I want to keep a list of those Setting Objects, I quickly decided that the TObjectList was a very good class to start with.

Creating the TdvSetting class

The explanation

Basically I need an object with a few properties like an Identifier (or Name, Caption), a Description (or Hint) and of course a Value. I will need to be able to read the value from the Registry and write it to the registry. Additionally when reading the value from the Registry I want to check if there is already something in the registry for the setting, and if nothing is found, the Default value should be used.

Just as with the TField and TStringField, I want to be able to get the Value of the TdvSetting as a String or as a Variant, so I added that code as well. Additionally I want to set the value of the TdvSetting as well. In the end, the descendant classes will implement most of this, but like with the TField in the VCL, I added some code which will raise an exception if a descendant class doens't implement a specific accessor.

This might sound a bit complex, but lets compare it with the TField and TStringField again. With a TStringField, you can set the value using aField.Value := theValue or with aField.AsString := theValue. Both things will work, but if aField is in instance of TField instead of TStringField an exception will be raised. What I did was implement that functionality as well.

For now we will focus on the Windows Registry, but as you notice it is a good idea to keep a few other possibilities ready. In the end, the only thing we care about is that we can store / load some settings. How or where these settings are stored isn't all that important, it just needs to get done !

The Code

  TdvSetting = class( TObject )
  private
    FValue        : Variant;
    FDefaultValue : Variant;
    FIdentifier   : String;
    FCaption      : String;
    procedure SetCaption(const Value: String);
    procedure SetVisible(const Value: Boolean);
  protected
    function GetAsBoolean: Boolean; virtual;
    function GetAsDateTime: TDateTime; virtual;
    function GetAsFloat: Double; virtual;
    function GetAsInteger: Longint; virtual;
    function GetAsString: string; virtual;
    function GetAsVariant: Variant; virtual;

    procedure SetAsBoolean(const Value: Boolean); virtual;
    procedure SetAsDateTime(const Value: TDateTime); virtual;
    procedure SetHint(const Value: String);
    procedure SetAsFloat(const Value: Double); virtual;
    procedure SetIdentifier(const Value: String);
    procedure SetAsInteger(const Value: Longint); virtual;
    procedure SetAsString(const Value: string); virtual;
    procedure SetAsVariant(const Value: Variant); virtual;
  protected
    function AccessError(const TypeName: string): Exception; dynamic;
    procedure SetVarValue( const Value : Variant ); virtual;
  public
    Constructor Create( const aIdentifier, aCaption : String;
                        const aDefaultValue : Variant ); virtual;

    destructor Destroy; override;

    procedure SaveToRegIni  (       aRegIni  : TRegistryIniFile;
                              const aSection : String ); virtual;
    procedure LoadFromRegIni(       aRegIni  : TRegistryIniFile;
                              const aSection : String ); virtual;

    procedure Clear; virtual;

    property DefaultValue  : Variant       read  FDefaultValue;
    property AsBoolean     : Boolean       read  GetAsBoolean
                                           write SetAsBoolean;
    property AsDateTime    : TDateTime     read  GetAsDateTime
                                           write SetAsDateTime;
    property AsFloat       : Double        read  GetAsFloat
                                           write SetAsFloat;
    property AsInteger     : Longint       read  GetAsInteger
                                           write SetAsInteger;
    property AsString      : string        read  GetAsString
                                           write SetAsString;
    property AsVariant     : Variant       read  GetAsVariant
                                           write SetAsVariant;

    property Identifier  : String          read  FIdentifier
                                           write SetIdentifier;
    property Caption     : String          read  FCaption
                                           write SetCaption;
    property Value       : Variant         read  GetAsVariant
                                           write SetAsVariant;
  end;

...

function TdvSetting.AccessError(const TypeName: string): Exception;
resourcestring
  SSettingAccessError = 'Cannot access Setting ''%s'' (%s) as type %s';
begin
  Result := Exception.CreateResFmt( @SSettingAccessError,
                                    [ Identifier, Caption, TypeName ] );
end;

procedure TdvSetting.Clear;
begin
  FValue := Null;  
end;

constructor TdvSetting.Create(const aIdentifier, aCaption: String;
  const aDefaultValue: Variant);
begin
  Create( aIdentifier, aCaption, aCaption, True, aDefaultValue );
end;

function TdvSetting.GetAsBoolean: Boolean;
begin
  raise AccessError('Boolean'); { Do not localize }
end;

function TdvSetting.GetAsDateTime: TDateTime;
begin
  raise AccessError('DateTime'); { Do not localize }
end;

function TdvSetting.GetAsFloat: Double;
begin
  raise AccessError('Float'); { Do not localize }
end;

function TdvSetting.GetAsInteger: Longint;
begin
  raise AccessError('Integer'); { Do not localize }
end;

function TdvSetting.GetAsString: string;
begin
  Result := ClassName;
end;

function TdvSetting.GetAsVariant: Variant;
begin
  raise AccessError('Variant'); { Do not localize }
end;

procedure TdvSetting.LoadFromRegIni(aRegIni: TRegistryIniFile;
  const aSection: String);
begin
  Assert( Assigned( aRegIni ), 'The aRegIni parameter should contain a TRegIni Instance' );
end;

procedure TdvSetting.SaveToRegIni(aRegIni: TRegistryIniFile;
  const aSection: String);
begin
  Assert( Assigned( aRegIni ), 'The aRegIni parameter should contain a TRegIni Instance' );
end;

procedure TdvSetting.SetAsBoolean(const Value: Boolean);
begin
  raise AccessError('Boolean'); { Do not localize }
end;

procedure TdvSetting.SetAsDateTime(const Value: TDateTime);
begin
  raise AccessError('DateTime'); { Do not localize }
end;

procedure TdvSetting.SetAsFloat(const Value: Double);
begin
  raise AccessError('Float'); { Do not localize }
end;

procedure TdvSetting.SetAsInteger(const Value: Longint);
begin
  raise AccessError('Integer'); { Do not localize }
end;

procedure TdvSetting.SetAsString(const Value: string);
begin
  raise AccessError('String'); { Do not localize }
end;

procedure TdvSetting.SetAsVariant(const Value: Variant);
begin
  if ( VarIsNull( Value ) ) then
  begin
    Clear;
  end
  else
  begin
    SetVarValue( Value );
  end;
end;

procedure TdvSetting.SetCaption(const Value: String);
begin
  FCaption := Value;
end;

procedure TdvSetting.SetHint(const Value: String);
begin
  FHint := Value;
end;

procedure TdvSetting.SetIdentifier(const Value: String);
begin
  FIdentifier := Value;
end;

procedure TdvSetting.SetVarValue(const Value: Variant);
begin
  raise AccessError('Variant'); { Do not localize }
end;

What does it do ?

Actually this piece of code doesn't do all that much. It just provides us with a base class we can now use as an ancestor for our other classes. Basically we have some ErrorHandling and a skeleton for our specific Setting classes.

Continued in Part 4

For some reason I had problems fitting everything into one single post, so I had to split it up an two parts. Go ahead and read the rest in part 4.

Well, we did get some time to think a little more about what our code is supposed to do, so we have a pretty good idea about it already. Sadly the people who originally created the code didn't really think about it. In this article we'll take a close look at how everything was programmed and we'll have a look at some of the disadvantages and how we should solve them.

The Old Code

Basically the developers though about it and they had the idea that settings should be read from the registry when the user wanted to edit them. Once the user finished changing the settings the code should store the new settings in the registry. Apparently they also had the idea to load the settings when the first form gets displayed and save them when it gets closed.

So, in the main form they had some code which looks like this :

procedure TfrmMain.FormShow(Sender: TObject);
var
  aRegistry : TRegistry;
begin
  aRegistry := TRegistry.Create;
  try
    aRegistry.OpenKey( '<THE_REGISTRY_PATH>', True);
    // FString, FInteger and FBoolean are private field declarations on
    // TfrmMain.
    FString  := aRegistry.ReadString( '<STRING_SETTING_KEY'  );
    FInteger := aRegistry.ReadInteger( '<STRING_SETTING_KEY'  );
    FBoolean := aRegistry.ReadBool( '<STRING_SETTING_KEY'  );
  finally
    aRegistry.Free;
  end;
end;

procedure TfrmMain.FormClose(Sender: TObject; var Action: TCloseAction);
var
  aRegistry : TRegistry;
begin
  aRegistry := TRegistry.Create;
  try
    // FString, FInteger and FBoolean are private field declarations on
    // TfrmMain.
    aRegistry.OpenKey( '<THE_REGISTRY_PATH>', True);
    aRegistry.WriteString( '<STRING_SETTING_KEY', FString  );
    aRegistry.WriteInteger( '<STRING_SETTING_KEY', FInteger  );
    aRegistry.WriteBool( '<STRING_SETTING_KEY', FBoolean  );
  finally
    aRegistry.Free;
  end;
end;

procedure TfrmMain.mnuEditSettingsClick(Sender: TObject);
var
  aEditSettingsForm : TfrmEditSettings;
begin
  aEditSettingsForm := TfrmEditSettings.Create( Self );
  try
    aEditSettingsForm.TheString := FString;
    aEditSettingsForm.TheInteger := FInteger;
    aEditSettingsForm.TheBoolean := FBoolean;

    if ( aEditSettingsForm.ShowModal = mrOK ) then
    begin
      FString  := aEditSettingsForm.TheString;
      FInteger := aEditSettingsForm.TheInteger;
      FBoolean := aEditSettingsForm.TheBoolean;
    end;
  finally
    FreeAndNil( aEditSettingsFrom )
  end;
end;

Will this work ?

As you can see, the code will be working. It will read the settings when the main form gets shown and store it in some private variables. When the main form gets closed, the settings will be stored. And there is even some code which will open a Edit Settings form, pass some values to it, and get some results back when the user closes the Edit Settings form by pressing the OK Button.

So what's the problem ?

Is the code executed at the right time ?

In my opinion the OnShow and OnClose events on the form arn't really the best places to execute this code. What if the settings included things related to the visual appearance of the form ? Do you want to read and change those each time this form gets shown ? Maybe you have some other settings which should get read even before the first form is shown ?

In any case you might want to read the settings or store them at different points during the execution of your application. In this example, that would require you to execute the OnShow event of the main form to load the settings. Even worst is having to rewrite or copy / paste the loading code in other locations. Believe it or not, but that's what's happening in a lot of cases.

What happens when a problem occurs while loading / saving the settingss ?

The code isn't perfect, and strange things will happen when a certain registry key doesn't exist. The code will raise an exception causing it to read or save only part of the settings and ending up with invalid settings. In our case, it would be nice if a default value was used when a certain registry key doesn't exist.

Additionally when the user opens the form to change the settings, and closes it using the OK button, the new settings are passed back to the main form, but are not stored in the registry yet. If some other part of your application now reads the settings from the registry again you might end up with different settings than the ones on your main form.

Is it really the responsibility of the main form to Load or Save settings ?

Well, in short NO ! Not at all !

What if we had to create a command line version of our application ? We might still need to read some settings from the registry, but we won't need any forms at all. What if I need to start a thread for some background processing, and need to read the settings in that thread as well ?

As you can see the Main From really shouldn't be responsible for the Loading and Saving of the settings. It can call a method to do the job, but the actual code should never be in the main form.

Another rule of mine is that a form should only contain code which has an influence on the visual aspect of the form or its components / controls. Reading settings and Writing settings doesn't have a visual inflence on the form, so it's code shouldn't be in a form. You might need to change some visual aspects based on what you read from the registry, but the actual reading itself isn't the responsibility of a form.

Is there a better alternative ?

Well, it's one thing to say that something is incorrect, but when doing so you should at least try to tell how to do it correctly. So, lets think a bit more about what we want and what we need. Generally speaking we want something to load and save application settings. It would be nice if we had some code we could use in whatever application we create in the future. It really doesn't matter how many settings we need to read, or what they are called, and what format they are the only thing we care about is that we can Load / Save / Edit and Use them. How this is done isn't our responsability but something the ApplicationSettings class should take care about.

If we need to use the settings in our applications we only need to use code which will look like this :

var
  aApplicationSettings : TApplicationSettings;
begin
  aApplicationSettings := TApplicationSettings.Create( '<OUR Registry Key>' );  
  try
    // Code used to load our settings  
    aApplicationSettings.LoadFromRegistry;
    
    // Code used to edit our settings
    if ( aApplicationSettings.EditSettings ) then    
    begin
      // Our settings got changed so we might want to do
      // something if necessary.
    end;
        
    // Code used to save our settings
    aApplicationSettings.SaveToRegistry;    
  finally
    FreeAndNil( aApplicationSettings );  
  end;
end;

Who's responsible for what ?

As you can see, our application / form or whatever doesn't really need to know how it should read the settings, it shouldn't really need to know how it is saving the settings, nor how we will display or edit the settings. The only thing it has to know is that we have Application Settings and we can use them.

Our Application Settings class on the other hand needs to know which settings the application needs, what kind of settings they are and how it should load / save each of those settings.

Are there any advantages to this approach ?

Absolutely, otherwise I wouldn't have taken the time to write all this down. Our main goal here is to use Delphi as an Object Oriented programming language, not just a RAD tool. We will be creating some classes based on our new approach, and our goal is to reuse those classes whenever necessary.

If we need to write another application tomorrow and it needs to save / load some application settings we will only have to let the system know which settings are needed, how they are called and what data type they are. All the rest of the code will simply be reused. We will spend a little more time creating the base classes and their code, but next time we need it, everything will be (almost) ready for us.

What's next ?

Well, we've been thinking and talking a lot so far, but we havn't really done any true coding yet. Maybe a few people are thinking they could have written the code in the time they read these two articles.

I'm quite sure that's possible, and I've seen it done ...

Sadly I've also been the guy who got hired 5 years after the application got written to debug the whole application in search of why something didn't work in some cases. I've also been the person who had to search through thousands of lines of code wondering why one setting never got saved or got replaced by an incorrect value. And yes, I've been that person who wished they had taken the time to think about their code before they actually started working on it :-P

Anyway, next time I'll show you how I would do it, and hopefully share some code with you.

In this series of articles I will try to show how you could easily improve your 'old' code with some simple OO techniques and some refactoring. When writing some Delphi Code I presonally have a few rules I abide by. It would probably require my a few pages to explain them all, but here are just a few to get you started with :

• Write down what your code is supposed to do
• Think before you start writing your first line of code !
• Sketch a little Class Diagram / Class Hierarchy if necessary
• If you copy / pasted the same lines of code more than twice, it's time to refactor it ! (same rule applies if you are writing the same code more than two times)
• Classes should do what they are responsible for, nothing more, nothing less
• Try to think in Objects with their responsibilities instead of thinking in procedures and processes !

To illustrate this I will be using a little example of some code which could be used in almost any application : Saving & Loading some applicaiton settings. It's a pretty simple task, but in quite a few occasions the code used to do it is ... well ... not the best example of OO development. So, lets take this example and see what we can do with our few simple rules.

A closer look at 'The Rules'

Write down what your code is supposed to do

I think pretty much every application will be storing some settings. It doens't really matter if you use a ClientDataSet, and INI File, a simple Text file or even the Windows Registry to do it. What really matters is that an application can have some settings, they user might be able to change those settings and the application will probably need to read the settings and save them.

Well that's about it really, we have written down what our code should do. Of course we might change this in the future or add some new things to it, but basically we have everything we need to get started.

An additional advantage we have now is that we have already written some very basic documentation for our code ! This is really a good way to do it, since most of the time, if you have to write the documentation once everything is finished, chances are you'll never have any documentation. Of course we still need the discipline to update our documentation if things change, but we have something to get started.

Think before you start writing your first line of code !

While writing out what your code is supposed to do, you should also get into the habit of thinking about how it's going to do it, what it will need, ... So, what our piece of code will need is :

• Some Application Settings
• Some way to load the settings
• Some way to save the settings
• Some place to save to and load from
• Some way to display the settings
• Some way to edit the settings
• Some form we will use for display / editing purposes
• Some way to use the settings in our application

In order to make it simple, we will assume that we will be storing our Application Settings in the Windows Registry for now. We could make it quite generic though and have a load / save mechanism for the Windows Registry / INI Files or any other presistance mechanism, but that's not the main focus (yet), so we'll stick with the Windows Registry.

What's next ?

Well, this is a good place to end this first article. In the next installment we'll be taking a look at some of the other rules, and maybe have a look at some 'old' code too and check how we could improve it. Meanwhile we have some time to think about what our code needs to do, and some time to sketch out a little Class Diagram as well ...

Delphi Everywhere

The message was very clear, but it came somewhat as a surprise to me when David I mentioned the Mission Statement : Delphi Everywhere. Later on during the session he even said Native Delphi Everywhere, mentioning Mac OS X, Linux, but also mobile devices. He even hinted at possibilities to build phone (even iPhone) applications using Delphi.

At that time I didn't really know what to think about it, but the possibilities of developing applications for Mobile Devices sounded, well ... to be honest, it sounded like a dream. But during the course of the other presentations, I noticed that they might actually be pretty close to fulfilling it !

Delphi Touch

Well, they actually called it Delphi Natural Input to be correct. The goal is to allow delphi and it's VCL components to interact with many different forms of input devices ranging from touch screens, surface tables, accelerometers, GPS, Speech, WebCams, ...

All these features will get included in a future version of the Delphi VCL. Since I am working on a Mac, and am using an iPhone, I had a pretty good idea about the possibilities, but I never thought it would be possible to achieve something like that in Delphi. Well, David I showed us a demo, and proved me I was wrong ...

The demo was actually pretty simple, and didn't require any programming at all. All you had to do was add a new GestureManager component to your application. The next step would be creating the gestures or using one of the many predefined gestures already available in the Gesture Manager. The only thing you had to do was add some code in the OnGesture event and execute some code based on the Gesture that triggered it.

For those who have been developing in Delphi, you could actually compare it to a TActionList in which you can add some default actions, and add your own custom actions as well.

At this point it became clear to me that the possibility of creating applications for Mobile Devices using Delphi wasn't just a dream. Apparently they have already spent quite some work on it, and the whole Gestures thing demonstrated that it could actually be done.

The Delphi Roadmap

I was glad to see that de team behind Delphi is very busy working on the next releases of Delphi. Apparently de developers have been divided into several teams working on a few bug projects. I will give you a brief list of those projects and what they will be focusing on. Don't ask me about release dates, since they didn't mention any. As David wisely said : There are 75 or more ways to ask us when it will be shipping, and there is only one right answer "When it's ready"

Project Weaver

• Project "Weaver" will mainly be focusing on larger and smaller IDE enhancements, improved usability and productivity.
• Added support for Natural Input devices like Touch, Gestures, ...
• Improved documentation and increased Team Productivity
• DataSnap with HTTP support, built in REST server, and .Net proxies for DataSnap
• IDE Insight (tm) - Keyboard access to everything
• Windows 7 API support and Direct2D
• Enhanced RTTI Support
• Source Code Control with a new Open Tools API interface that provides support for Source Control Management (Weaver will have some Subversion Implementation)
• .Net Aspect Oriented Programming (this seemed quite impressive to me)

Project Delphi X

• Cross-platform Windows, Linux and MacOS

Some other features under consideration :

• Cross-platform component library
• DataSnapX with the ability to create both the Server and the Client on Windows, MacOS, Linux and the Web

Project Chromium

• The main thrust of Chromium will be quality, quality and quality…
• Focus on developer productivity (Enhancing usability, Remove long-standing issues, Focus on closing as many bugs as possible, Setting a new standard of reliability ...
• Lightweight O/R mapping
• Documentation of the OTA
• A new Databinding model allowing binding to almost any property on a control.
• More integration with the database tools

Project Commodore

• Bring native 64-bit development to Delphi, C++ Builder and the VCL

Some other features under consideration :

• Full compiler, RTL and VCL support for native 64 Compilation
• Multi-Core / Multi-Threaded applications
• Support for parallelization in the RTL

And much more to come

It looks like there is a lot more to come, and some projects might come in Parallel. Sadly, no information was given on when a specific product would be available to the public. The only thing David I mentioned was that the plan is to get a new version of Delphi each year.

TMS Smooth Controls : TAdvSmoothListBox

TMS Smooth Controls

Here in Belgium we have quite a few Delphi developers, and we also have companies like TMSSoftware who are developing some very nice components. There were some a few people from TMS Software in the room, and they gave us a brief demo of their TMS Smooth Controls Pack which is a set of feature-rich, sophisticated looking & smoothly animated controls.

The controls really looked impressive and immediately gave me the impression you would have when using an iPhone application. The components looked clean, pretty, had lots of animations.

Those of us who have been using an iPhone know what I am talking about. When navigating from one page to the other on the iPhone's applications screen, you get a smooth animation instead of simply repainting the whole screen. Well, the Smooth Controls did exactly the same thing on Windows. This gave everything a smoother and more visual look and feel

Conclusion

I actually missed the first part of the day due to traffic, but I gladly got there in time for the Delphi Roadmap, and I must say, it looks impressive. There have been times when we didn't know what to expect from Delphi, and some people even thought the good old days were over for Delphi. For those of you who are still hesitating about the future of Delphi, ... well, ... let me tell you :