EmbarraWhat?, Embarcedar, Embarcadero...

Well, not quite breaking news (anymore after one day), CodeGear is sold to Embarcadero Technologies.

I have mixed feelings with this sell, at one hand it is great that CodeGear finally sails into a safe harbour on the other hand it is sad that the Borland brand link with development now is vanished. Borland, the company that brought us Turbo Pascal, Delphi, (to name a few) and all that other exciting stuff.

Did you know that Embarcadero is a wharf, which appears to be a pier where ships can land? Well if that is not a safe harbour!

Although I don't know the company Embarcadero (still not a very easy name to remember;-) ) it looks like a good deal for both CodeGear and Embarcadero and CodeGear tools users. Time will tell.

Congrats CodeGear!

Linq to SQL

Inside that other Development tool that I use, I found an interesting link to Luca Bolognese's  blogpost about Linq to SQL. You really should watch the video where he shows how it works in C#.

Linq to SQL is about accessing relational data with LINQ. (Language Integrated Query).

I find this really amazing stuff. It looks very easy to map data from a database to objects in your code.

The video gives a good intro on how this new stuff works. If you want to know more about LINQ, like me, you should check out Charlie Calvert's blogpost "Links to Linq" with a whole bunch of links and information.

Delphi roadmap update

The Delphi and C++ Roadmap has been updated. It contains only updates for the native side of the fence. According to Nick's blogpost a separate update is in the make for .NET.

In short Tiburon is planned for second half 2008, focusing on:

1. Connectivity (Enhanced Datasnap)
2. International development (read Unicode)
3. Delphi language Enhancements

Commodore is planned for mid 2009 and will focus (among other things) on native 64bit compilation and parallelization in the RTL. 

For all the details go checkout the roadmap.

Blaise Pascal Magazine

There is a new international magazine about Delphi and related languages! The magazine has it's root in the HCC (Hobby Computer Club) from the Netherlands. The Pascal Usergroup (PGG) section of this club offers for many years a magazine in ducth about Delphi languages for beginner, intermediate and expert users.

They now have gone international with an englisch version!

According to their website there will be a printed and a free download version:

The printed version contains 40 pages and entitles you to download all the code free of charge.
You will receive all issues for one year for only € 40,00.
A subscription to the download version is free, but you must pay for each code -or programm with code- download.

I think this is great news for Delphi!
You will find the table of contents of their first issue here.

Go get it here: http://www.blaisepascal.eu/.

Tiburion: A smooth Unicode shift...

Nick Hodges talks about the Unicode Shift in the new coming Delphi release code name Tiburon.
He talks about the (four) steps that were taken to get everything unicode compliant, which resulted in :

1. A new compiler with new inherent UnicodeString type
2. A new RTL using new string type routines (i.e. many new compiler helper functions in System.pas).
3. An updated VCL using the new RTL that allows the string type to easily "float" to the UnicodeString type
4. A fully functional IDE compiling with the new Unicode Compiler, RTL, and VCL.

Looks like it is going to be a smooth shift...
Anyway one of the first things coming out for the new release and an interesting read!

What is wrong with this code?

unit Unit3;

interface

uses
  Windows, Messages, SysUtils, Variants,
  Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm3 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
    procedure MyFunction(x : string);
  end;

var
  Form3: TForm3;

implementation

{$R *.dfm}
procedure TForm3.Button1Click;
begin
  MyFunction('test')
end;

procedure TForm3.MyFunction;
begin
  ShowMessage(x);
end;

end.

Well after using Delphi for more then a decade I would say that this code would not compile because of the fact that both MyFunction and Button1Click misses their parameterlist in the implementation section.


But in fact it is perfect Delphi code as it compiles without a problem!


Never, ever I have seen code like this before, until today in a project that I do maintenance for.


Don't try this at home, because it makes,imo, your code a nightmare to read.

European Online Webinars

CodeGear Europe, is running (and has been running) a nice serie of Webinars. In april they are running 6 webinars about, among other things, XML, SOA and Webservices with Delphi.
Besides Delphi there are also webinars about Delphi for PHP, Blackfish, C++ Builder, JBuilder and 3rdRail.

On the CodeGear European Event Calendar you will find both, the scheduled events and playback of the recorded webinars.

Using Assert

In a project that I herited there is massive use of Assert. Personally I did not use Assert that much, but it has some nice advantages during developing an application. (More info on Assertion in general)

What does it do?
Assert can be used as a debug tool. Assert tests boolean expression, and will halt execution if that expression is not true. If that happens, it will raise an EAssertionFailed exception.

How to use it?
This is an example, how you can use Assert in your code.

procedure TForm3.DoIt(AStringList : TStrings);
begin
  Assert(Assigned(AStringList), 'Test ');
  ShowMessage(AStringList.Text);
end;

procedure TForm3.Button1Click(Sender: TObject);
begin
  DoIt(nil);
end;

Clicking the button will raise the EAssertionFailed exception:



Generally you don't want that the end users see this message. Therefor you can disable/enable assertion throug the $C directive or your project options dialog. If you disable Assertion, the example code will lead to an Acces violation, so normal exception tracking is needed anyhow.

The Delphi help about Assert:

The $C directive enables or disables the generation of code for assertions in a Delphi source file. {$C+} is the default.

Since assertions are not usually used at runtime in shipping versions of a product, compiler directives that disable the generation of code for assertions are provided. {$C-} will disable assertions.

More on going virtual, more experience

As I told you in this blogpost I was thinking about moving my production environment into a virtual machine. I got some really great feedback on that post, thanks for that!

Executing on that thought, I made two VM's. Here is my experience so far:

My hosting Laptop
My laptop (Dell Inspiron 9300) is two years old with the following specifications:
- Windows XP pro
-Processor: Intel running at 1,86 Ghz (Don't know exact type)
-1,5 GB memory
-Max memory available for VM 512MB
I do most of my development on this laptop.

My hosting PC
-Window Vista Business
-Processor: Intel Duo Core
-2GB memory
-Max memory available for VM 1024MB

My Delphi VM (Windows XP pro)
I made a 'Delphi' VM with Delphi 7 (for older projects), BDS2006 (for Winforms development) and RAD Studio 2007.
Currently I am using Microsoft Virtual PC 2007 to make the virtual machine. Why? Simply because it is free and I am still in an experience state here, just making the big picture on going virtual. I believe VMWare has more options, and, as I found out, Virtual PC is no good for Linux distributions. (Use Virtual box for that).
I installed all that was necessary for Delphi, the IDE, third party components etcetera in the VM.
I use Visual SourceSafe for version control and keep the source files within the VM because I had some trouble keeping the shared folders alive. This was probably a low memory issue. So my source database is on my hosting laptop, which is backed up as usual.
Currently I 'synchronize' the sources through SourceSafe between the VM and the host. (I still develop on the host...)

Performance
On my hosting laptop (512MB) Delphi 7 works fine, but BDS2006 and RAD Studio 2007 are slow. Most annoying in BDS2006 and RAD Studio is the slow typing, which makes it kind of unworkable.
On my hosting PC, with twice the available memory RAD Studio performance is OK.

My Ubuntu VM (Ubuntu 7.1)
Well since we are going virtual it is easy to test some OS from the other side of the fence. Installing Ubuntu into Virtual PC did not work (black screen). So I used Virtual Box instead, as someone suggested in the feedback of the last post.
Installing Ubuntu is amazingly easy, did not expect that so I was suprised.
Kylix 3:
I tried to install Kylix 3, but with no luck so far. This has probably most to do with my (missing) Linux skills. ;-) (Have to investigate this further)
Lazarus:
I managed to install lazarus pretty easy. Cool I can make an application for Linux now. ;-)

Conclusion
At this moment I will not go virtual completely. First I will have to upgrade the internal memory of my laptop upto at least 2 GB. But more memory, of course, would be better. (4GB?)
However it is nice to know that if my laptop, or installation, crashes I now have a complete installed development environment as backup, making the downtime almost zero.
The choice for the right virtual machine software is depending on what you do within the VM. However you could use more than one product. Virtual Box is a great alternative for both Windows and Linux VM's.
Possible future scenario:
Buy a new laptop without a preinstalled Windows (Vista). Install Ubuntu (or another Linux distro) on that laptop and run Windows XP in a VM..........

2008: Some thoughts on going virtual

One of the goals for me in 2008 is to bring my production environment over to a virtual machine. 

That should give the following benefits:
1. Complete installations can be backed up, so if a future update fails, it is easy to step back in time. (Less downtime)
2. It is easy to make multiple backups, with multiple states of the installation.
3. It is easy to take you complete production environment with you.
4. More flexible for setting up new software without hurting your existing software. (Testing new technologies etc.)

The benefits are clear, more secure, less downtime in case of an event, and more flexible.
First question that comes to mind thinking about going virtual is:

How to set up a VM environment as efficient as possible?

The answer to this question is, of course, specific for each situation. Because I have never done this, I will share with you how I think about settings things up. If you have any tips, please step in!

I use, the two major IDE's in the market today, for my development, namely CodeGear RAD Studio and Microsoft Visual Studio. The latter is for .NET development only, and mostly ASP.NET development.
So I think about setting up two seperate VM's: (They will be based on Windows XP pro)

1. Delphi VM
- Delphi 7 (for older projects)
- BDS 2006 (.NET personality for Winforms .NET 1.1 development)
- RAD Studio 2007
- Delphi third party components
- Visual SourceSafe for version control

2. Visual Studio VM
- Visual Studio 2005 (Winforms/ASP.NET developement)
- Visual Studio 2008 (future...)
- Third party components
- Visual SourceSafe for version control

On each VM I completely install all necessary software and components. After that I will backup those VM's as the basic production environment setups. With each future update (IDE, components), I will update those basic environments also, keeping them up-to-date. If an update fails there is no problem, just use the last backed up clean environment.

The source code and SourceSafe
On the hosting machine, my laptop by default, I will install all other necessary applications, like Microsoft SQL Server, Office etcetera.
I will keep my application source codes located on the hosting machine, which I can reach in my VM through shared folders. Doing this, I can backup them as usual. With Visual SourceSafe in VM, I can check out files on my laptop, and alter them within the VM.

Well just some thoughts about setting up a development VM.

Happy new year!!

RAD Studio 2007 December update released!

CodeGear just released the December update for RAD Studio 2007, as well as the update for Delphi 2007 and C++ Builder 2007.

Looks like there are a lot of fixes.
284 Core bugfixes
93 Delphi 2007 fixes
46 C++ Builder fixes
157 Delphi 2007 .NET fixes

According Nick Hodges blogpost about the upgrade it should not be a too long update this time. Because of the fact that it is a binary update, all unofficial patches that were applied should be uninstalled.

Chris Pattinson looks back at 2007, from a QA stand point of view, in his blogpost CodeGear Quality Review 2007. 7006 defects are fixed since 1 january 2007!

You can download the update at the registered users download page. Or check for updates within the IDE.

Programming in Delphi sins #3

In this serie I will tell you, what we find a sin, in Delphi programming.

Using published properties of components from another class
When you place components on forms and datamodules in Delphi they are published by default. In other words you can use components in your form that belong to other forms/datamodules. If you do this, those forms will be tightly coupled and therefor this is not quite a good OOP practice.

type
  TdmMain = class(TDataModule)
    //These components are published and direct 
    // accesable by other forms/datamodules
    SomeDataSet: TADOTable;
    adsAnotherDataSet: TADODataSet;
  private
    { Private declarations }
  public
    { Public declarations }
  end;

Suppose you have a form that uses a datamodule with some dataset on it and you want to show some field value in a label on your form. You could do it like this:

procedure TForm3.SetCaption;
begin
 SomeLabel.Caption := 
 dmMain.SomeDataSet.FieldByName('SomeField').AsString;
end;

This is bad practice. Suppose that, something simple as the name of the field changes, you would have change both your datamodule, and your form.

Solution:

Use properties and functions (getters), not properties from published components.

In the datamodule:

property SomField : string read GetSomeField;
procedure TdmMain.GetSomeField : String;
begin
  Result := 
  SomeDataSet.FieldByName('SomeField').AsString;
end;

In your form:

procedure TForm3.SetCaption;
begin
  SomeLabel.Caption := dmMain.SomeField;
end;

A more dramatic way to avoid use of published properties is to move all published properties into the private section of the class.

This gives you best practice, however if you use dataware controls, you then should couple them manually.

So for the sake of dataware controls we keep them published, but always write properties or getter functions to get values in code.

Programming in Delphi sins #2

In the first episode of this serie I talked about avoiding the default auto-create function for forms and datamodules in Delphi.
As Zarko Gajic (delphi.about.com) pointed out in the comments I made another sin ;-) in the example code. Always something to learn! Thanks for the tip Zarko!

Well here it goes #2:

Never use a owner if you create a component/form yourself and free it instantly
So don't do this: TForm3.Create(self);

procedure TForm5.Button1Click(Sender: TObject);
var
  MyForm : TForm3;
begin
  MyForm := TForm3.Create(self);
  try
    MyForm.ShowModal;
  finally
    MyForm.Free;
  end;
end;

But do this: TForm3.Create(nil);

procedure TForm5.Button1Click(Sender: TObject);
var
  MyForm : TForm3;
begin
  MyForm := TForm3.Create(nil);
  try
    MyForm.ShowModal;
  finally
    MyForm.Free;
  end;
end;

If you pass self (in this case Form5) as the owner you rely on Form5 to free it when form5 is destroyed. Beside maintenance confusion it also has a backdraft on performance.

Zarko has a great article on this:

A warning on dynamically instantiating components

Always great to learn something new!

Programming in Delphi sins #1

In this serie I will tell you, what we find a sin, in Delphi programming.

Using auto create forms and datamodules
Standard Delphi will create automatically all forms and datamodules for you. This gives you a headstart when you are first learning Delphi, but in the end it will give you a headache!

Sooner or later you begin to wonder where that 'Form1' object is coming from. (It is in fact a variable in the interface section of his own unit)
Other issues:

1. Your program becomes slower, consuming more memory then needed with many forms created.
2. Bugs will be harder to track, because you just can not know the state of all your forms and datamodules. Code could run, without you knowing about it.
   
   

Solution:
Turn off auto creation of forms in the options Dialog-VCL Designer tab, and create your forms/datamodules when you need them, and free it when you are done with it. In existing projects remove those forms from the auto create forms list in the project options.

Create a form when you need it, using your own variable:

procedure TForm5.Button1Click(Sender: TObject);
var
  MyForm : TForm3;
begin
  MyForm := TForm3.Create(self);
  try
    MyForm.ShowModal;
  finally
    MyForm.Free;
  end;
end;

Remove the 'global' var in unit of the newly created forms and datamodules, you just don't need them:

unit Unit3;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, 
Graphics, Controls, Forms,  Dialogs;

type
  TForm3 = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

//Remove this global var, which is 
//the instance that is created with
//the auto create forms option turned on
var
  Form3: TForm3;
//--

implementation

{$R *.dfm}

end.

String parameters tip

Chris Bensen has a 'small' tip, which in fact is a great tip.
He suggest to always pass strings as const or var. If you pass them by value extra (unnecessary) assembly is being generated.

Read his blogpost String parameters in delphi (Don't forget the comments)

Some memory leak pitfalls

Just installed the professional version of Eurekalog, which is, imo, a must have tool for tracking exceptions and memory leaks in your Delphi Win32 applications.
This tool, and of course any other tool out there that does the same, really helps you to track down exceptions fast. For me, even more important, is the fact that it helps you track down memory leaks as well.

No matter how secure you program, sooner or later, you will loose some memory. Here some pitfalls:

1. Let it be clear where, and who, will free the object
It must be clear where objects are created (read memory for the object is allocated) because otherwise you are in danger for memory leaks.
Functions that create their result are dangerous in this manner. Suppose a function that creates a TStringList, and returns it as it's result:

function TForm3.GetSomeStringList : TStrings;
begin
  Result := TStringList.Create;
  Result.Add('one');
  Result.Add('two');
end;

procedure TForm3.DoSomethingWithaStringlist;
var
  MyStringList : TStrings;
begin
  MyStringList := GetSomeStringList;
  try
    ShowMessage(MyStringList.Text);
  finally
    MyStringList.Free; //Free it!
  end;
end;

In this case, the calling method, and the developer must realize that it must free the stringlist, after it is ready with it. This is not always clear in this scenario. A better solution would be to pass your own created Stringlist to the function. Like this:

procedure TForm3.GetSomeStringList(
                    AStringList : TStrings);
begin
  AStringList.Add('one');
  AStringList.Add('two');
end;

procedure TForm3.DoSomethingWithaStringlist; 
var
  MyStringList : TStrings;
begin
  MyStringList := TStringList.Create;
  try
    GetSomeStringList(MyStringList);
    ShowMessage(MyStringList.Text);
  finally
     MyStringList.Free; //Free it!
  end;
end;

It is better to have both, the Create and Free in the same try finally block if possible. Can't go wrong if you code it like this.

2. Always free your own objects nobody else does it for you 
Sometimes it is easy to add to, for example a listbox, also an extra object with more information of the selected item. When filling the items (a TStringlist) you pass on a reference to the listbox item. Later you can use that information to do, whatever you want to do.


Your code could look like this:

procedure TForm3.Button1Click(Sender: TObject);
var
 obj : TSomeObject;
begin
  obj := TSomeObject.Create;
  obj.SomeInfo := 'This is number one';
  ListBox1.Items.AddObject('one', obj);
  obj := TSomeObject.Create;
  obj.SomeInfo := 'This is number two';
  ListBox1.Items.AddObject('Two', obj);
end;

To read the data on the selection you can then read the extra info like this (just an example here):

 ShowMessage(
   (ListBox1.Items.Objects[ListBox1.ItemIndex]
    as TSomeObject).SomeInfo);

What you must not forget in this situation is to free all the objects when the application or form is destroyed! The Listbox does not do that for you!

So in the destroy of your form, free all the objects in the listbox like this:

  for i := 0 to ListBox1.Items.Count - 1 do begin
    Listbox1.Items.Objects[i].Free;
  end;

Conclusion is that a good coding style helps you to avoid memory leaks. Tools like Eurekalog helps you to trace them easily and are a great learning resource for where you enter memory pitfalls

Time to shift to second gear

CodeGear exists one year!

I could sum up everything that happened this year, but Marco Cantu did a great job in his blogpost One year for CodeGear. (Very nice read!)

CodeGear congrats! And let's shift to second Gear shall we?

BugNET review, download, install and track your issues!

Bug tracking is a very important part of software development. We do projects for a lot of different company's which almost all have their own way of bugtracking, if they have it all.
Basically bugtracking is maintaining a list of issues, administering some dates, like report date to solved dates.
When you work in small teams (<3 person) a simple Excel list will do it, but in greater teams, on different locations it just becomes a mess.

Time to investigate a better solution, a bugtracking system.

We had a few requirements:
- The tool should be web based (Running on IIS)
- Projects with team members and roles
- Projects/Users only available for assigned persons
- Possibility to add fields for a specific project on the fly
- E-mail notifications for status changes etc.
- Not only suitable for bugtracking, but issue tracking in general
- If open source then ASP.NET C# as first choice
- Fast and nice looking

BugNET
The first open source project we tried was BugNET

BugNET is an issue tracking and project issue management solution built using the ASP.NET web application framework. Email notifications, reporting and per project configuration of fields and values allows efficient management of bugs, feature requests, and other issues for projects of any scale.

We downloaded it, installed it and loved it! Within 10 minutes we had an Issue tracking solution that met all of our requirements!

In BugNET you can create projects, assign team members to it giving them a standard role from Project Manager to Reader. You can also create own roles per project. A project can have categories (for instance the modules of an application) and versions that can be used as milestones for the issues. Those milestones easily translates themselves into a roadmap.
The project summary page gives a good overview with, from left to right, open issues per milestone, per category, per assignee, per status, per priority and type.
Issues can have:
- Comments
- Attachments
- Related issues
- and even time tracking

Issue changes can be notified by e-mail, and even RSS.
BugNET also supports a report solution which allows you to report to screen, PDF and Excel.
The user interface is looking nice, clean and to the point.

BugNET has the following requirements:
- IIS 5 or later
- Microsoft .NET Framework v2.0 Redistributable
- Microsoft Report Viewer Redistributable 2005
- Microsoft ASP.NET AJAX 1.0
- Microsoft SQL Server

More on the installation can be found on the BugNET documentation page.

If you are looking for a issue(bug) tracking management solution you really should give BugNET a try!

Watch your memory

Delphi has a nice feature (since version ??) to check whether you leak some memory in your project. All you have to do is set the ReportMemoryLeaksOnShutDown property to true in your project file.

begin
  ReportMemoryLeaksOnShutdown := true;
  Application.Initialize;

If you forget to free an object you will get an unexpected memory leak exception when you close your application.

This is nice, however we always release allocated memory, don't we?;-)

Although it is nice to know that you leak some memory the messagebox does not help us to find out where it happens. It only reports the type of object, and the spilled memory in bytes.
In the marketplace there are several tools that can be used to signal memory leaks. One in particular, which I am evaluating right now, is Eurekalog.
You can use this tool to catch exceptions and memory leaks in your application. A detailed log file, with call stack, will tell you exactly the location (unit and linenumber) in the source of the unfreed object. Double clicking a line in the call stack opens the unit at that line in the IDE.
Another nice feature of Eurekalog is that you can activate it within your application, so that whenever your user hits an unexpected exception, or memory leak he/she can send the report to you by e-mail or even sent it to your bug tracking system.

The Eurekalog log file for the above memory leak looks like this:

Although we always free memory, use the try...finally construct, you will leak memory sooner or later. Tools like Eurekalog can help you tracking them down easily. Do you know more sophisticated tools, like Eurekalog, to track down memory leaks?

.NET Enumerator basics

I hereby declare this week as the week of the enumerator. ;-)
Hallvard Vassbotn started this week with an excellent post on using enumerators patterns on your own collections. You should really give this high School enumeration stuff, a read!

The .NET Framework it self offers a lot of basic functionality for enumerators. It is friday so let's take a look on some basics here:

Sometimes it is necessary to let a user pick a value from a enumerator type. For example you want the user to pick some property value of a component, which is enumerator. You could, of course, fill a combox with string values by hand (keeping the order), but in future releases the list could extended, having you to alter your code.

Looping an enumerator
It is easier then to simply loop through the enumerator type. Update! In Delphi win32 this is not possible. This is false! Uli commented that it can in Delphi Win32!, using the Typinfo unit. (See the code in the comments)

In .NET however this is possible using the Enum.GetNames method.
 
In C# you code looks like this:

foreach ( string s in Enum.GetNames(typeof(SeriesChartType)) )
{
   Messagbox.Show(s);
}

the equivalent code in Delphi .NET is:

for s in Enum.GetNames(TypeOf(SeriesChartType)) do begin
   MessageBox.Show(s);
end;

Exists a value?
Check if a enumerator value exists in a enumerator type with the IsDefined method.
Delphi .NET code:

s := 'Point';
if Enum.IsDefined(TypeOf(SeriesChartType), s) then
  MessageBox.Show('Yes')
else
  MessageBox.Show('No');

Conclusion, the .NET framework Enum class, which is the base class for all the enumerator types, adds valueable methods to the basic enumerator types.
More information can be found on MSDN here.