We also want to thank all testers who participated in TestRail’s beta test. Without your feature suggestions, ideas and bug reports, the 1.0 certainly wouldn’t be what it is today. We’ve got more than 350 beta signups during the beta and are really grateful for all the feedback and emails we’ve received. Thank you! If you participated in the beta test, please check your email inbox for a small TestRail launch present.

When we released the first beta versions of TestRail last August, we didn’t plan for such a long beta phase. We intended to release a few beta versions and release it in November 2009 at the latest. Based on the feedback we received during the beta, however, it became apparent that TestRail would benefit from a few critical enhancement that we wanted to add before the release (such as test plans and configurations, nested sections including drag&drop, print support and importing/exporting).

The feedback during the beta made us confident that a modern and fresh approach to test management is needed and it was great to see that it was so well received by beta testers. There are still a lot of things that didn’t make it into the 1.0 that we want to see in the future of course, but I believe we’ve created a strong foundation for future enhancements and improvements.

We’ve updated TestRail’s website with new screenshots and a product tour as well as pricing details and licensing information. To celebrate the release of TestRail we are offering special introductory prices, so make sure to evaluate TestRail soon if you are interested in the tool. You can download a free and fully-functional trial copy of TestRail from our website.

As usual, the change log and update instructions for this release can be found in our forum. If you have any question about TestRail or this release, just let us know!

We wish all customers, friends and partners happy holidays and a successful new year 2010! We had a great year here at Gurock Software and reached some important milestones such as completing a critical customer project, launching our new website, improving SmartInspect, relaunching DelphiFeeds.com and releasing the first TestRail beta.

Next year will definitely be an interesting (and busy!) one for us and we will start with releasing TestRail in January, moving to a new office (again) and relaunching our customer portal and online shop.

We are looking forward to working with you again next year!

Unfortunately, Delphi never had good (built-in) run-time support for stack traces. The features for stack traces during debugging in the IDE are/were okay, but there were nothing in the language or framework which helped you to find out programmatically where an exception occurred at run-time and, more importantly, how it got passed to your exception handler (besides the original exception address, maybe). So, I was happy to see that Delphi 2009 finally introduced a new StackTrace property which, I hoped, would return a full-blown stack trace when you caught an exception.

The initial happiness soon wore off when I realized that the StackTrace property was really just a placeholder to return a stack trace from a possible stack trace provider rather than a real stack trace implementation. So, without such a provider (and there’s none that comes directly with Delphi), there is still no way to get a stack trace for your exceptions. Though a bit disappointing, the good thing is that there’s now finally a standardized way to get a stack trace, even if it’s not implemented by default.

Exception reporting tools such as Eurekalog or madExcept or debug helpers such as the JclDebug unit can register themselves as providers and use their engines to return a stack trace when an exception is raised. I’ve built a small unit which demonstrates this with the Jcl in combination with our logging tool SmartInspect and I’ve heard Fabio of Eurekalog is working on a similar feature for his component:

unit StackTrace;

interface

uses
  SysUtils, Classes, JclDebug;

implementation

function GetExceptionStackInfoProc(P: PExceptionRecord): Pointer;
var
  LLines: TStringList;
  LText: String;
  LResult: PChar;
begin
  LLines := TStringList.Create;
  try
    JclLastExceptStackListToStrings(LLines, True, True, True, True);
    LText := LLines.Text;
    LResult := StrAlloc(Length(LText));
    StrCopy(LResult, PChar(LText));
    Result := LResult;
  finally
    LLines.Free;
  end;
end;

function GetStackInfoStringProc(Info: Pointer): string;
begin
  Result := string(PChar(Info));
end;

procedure CleanUpStackInfoProc(Info: Pointer);
begin
  StrDispose(PChar(Info));
end;

initialization
  // Start the Jcl exception tracking and register our Exception
  // stack trace provider.
  if JclStartExceptionTracking then
  begin
    Exception.GetExceptionStackInfoProc := GetExceptionStackInfoProc;
    Exception.GetStackInfoStringProc := GetStackInfoStringProc;
    Exception.CleanUpStackInfoProc := CleanUpStackInfoProc;
  end;

finalization
  // Stop Jcl exception tracking and unregister our provider.
  if JclExceptionTrackingActive then
  begin
    Exception.GetExceptionStackInfoProc := nil;
    Exception.GetStackInfoStringProc := nil;
    Exception.CleanUpStackInfoProc := nil;
    JclStopExceptionTracking;
  end;
end.

The unit merely starts and stops the exception tracking of the Jcl, implements a minimal stack trace provider and registers for the Exception provider events. The GetExceptionStackInfoProc and CleanUpStackInfoProc functions are automatically called by the RTL to give the provider the opportunity to initialize and cleanup the stack trace after an exception occurred. GetStackInfoStringProc is called indirectly when you access the StackTrace property and is responsible for returning the actual stack trace.

So, how do you use this unit? Let’s have a look at the following example:

...

uses
  ..., StackTrace;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    procedure SomeMethod;
  end;

implementation

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    SomeMethod;
  except
    // Log the exception: We use SmartInspect here because it has
    // built-in support for Exception.StackTrace but you could also
    // access the StackTrace property here directly.
    SiMain.LogException;
  end;
end;

procedure TForm1.SomeMethod;
begin
  raise Exception.Create('A test exception');
end;

...

As you can see, using this unit is just a matter of adding it to our uses clause. It won’t get any simpler than that. The unit will take care of registering/unregistering itself as a stack trace provider and when you now access the StackTrace property of an Exception object, you will get a detailed stack trace. To include the method names and line numbers in the stack trace, make sure to let the linker include debug symbols into your application and to enable the ‘Use debug .dcus’ option in case you also want line numbers from the VCL and RTL methods.

The SmartInspect Console showing the stack trace of an exception

Now, when you use SmartInspect for logging and have a stack trace provider registered, all your logged exceptions automatically include the exception’s call stack. Pretty useful, isn’t it?

As usual, existing SmartInspect customers can download the new release from our customer portal. If you are interested in giving SmartInspect a try, please download the updated trial version with Delphi 2010 support from our website.

SmartInspect SQLite log viewed in SQLiteSpy

The logging protocol automatically creates and initializes a new SQLite database on its first use, making it very easy to deploy application with it. All SmartInspect packets such as log entries, watches and process flow entries are supported and stored in the resulting SQLite database. Please note that the protocol has been written for Delphi 2009, but there are only a few changes required if you want to use it with an older Delphi version. Update: The protocol works with multiple Delphi versions out of the box, including Delphi 2007 and Delphi 2009.

Until our upcoming new website with a more useful SmartInspect resources section has been launched (scheduled for next month), you can download David’s protocol here:

Download (5 KB)

We have just switched DelphiFeeds.com to the new website, after it has been tested by around 50 users in the past 2 weeks (all beta accounts and data have been moved to the new site, too, of course). Thanks to everyone who tested the new site and provided feedback! As a result of the feedback we’ve received, we have added an additional option to hide the popular section on the start page, allowing you to see more postings at once without scrolling (see the My Settings page for available options). So if you are a regular DelphiFeeds.com reader, make sure to create an account and start voting!

Popular postings, i.e. postings with many votes, are promoted to the Popular section of the front-page of the new site and thus get more attention. Popular postings are also featured on the new Popular pages, which makes it easy to track the most popular postings over time.

The new sidebar and widgets allow you to configure which newsgroups and community resources you want to see, and in which order they are displayed. We will add additional newsgroup and feed widgets soon, so if you have any suggestion for additional feeds that should be included, please let us know.

You can now also stay up-to-date on Delphi news and Delphi blog postings via Twitter by following @delphifeeds. This isn’t really a new feature and the DF.com crawler has been twittering for a few months now, but we haven’t announced it yet. So if you missed this, make sure to follow @delphifeeds!

We also finally updated the Blog of the Year award and determined the winners. It took us (a lot!) longer than expected, but there were always more important things to do, so my apologies for the delay. Anyway, congratulations to the blog authors and winners of the prizes and thanks to the prize sponsors!

So if you haven’t yet, make sure to check out the new site and please provide feedback. If no major issues come up during the beta, we will switch to the new site next weekend.

I understand that there are many Delphi users who want to upgrade to Delphi 2009 to benefit from additional features but don’t care about the Unicode improvements (or already use a different technique to support Unicode such as the TNT Controls). Adding this compatibility mode would therefore be a great short-term solution for them but would result in huge technical debt for CodeGear.

For CodeGear, this would mean supporting two parallel versions of the VCL for at least the next few versions of Delphi. What a support and maintenance nightmare! Likewise, third-party vendors would have to ship two different versions of their products for Delphi 2009 and beyond. One compiled with Unicode support and one without. Again, a maintenance nightmare.

I admit that porting real-world applications to Delphi 2009 can be quite a bit of work. The just released version of SmartInspect now uses Delphi 2009 for the SmartInspect Console. Previous versions were built against Delphi 2006 and I can say that the transition wasn’t as smooth as I hoped for. Like Babniks product, the SmartInspect Console already supported Unicode by using WideStrings and the TNT Controls, so there wasn’t a need to update to Delphi 2009 just because of Unicode. But we wanted to fix a few Vista related bugs and other glitches and Delphi 2009 includes fixes for most of them. So we decided to give Delphi 2009 a try.

It turned out that converting the Console itself wasn’t that big of a problem. The warning messages of the Delphi 2009 compiler are really helpful and we got most of the Console running within about two weeks. A bit more problematic were some no longer maintained third-party controls and it took two more weeks to get the Console to a really stable state. That’s more than I expected but still okay for such a one-time conversion (the Console has about 50K LoC + forms, the unmaintained third-party controls were about 10K I guess).

In retrospect, I think it was well-worth the time and Delphi 2009 feels like a good version. The IDE is much more stable than Delphi 2006 and the language and VCL finally got some much-needed improvements. We are also happy that we could throw away the WideString and TNT related code. Using Delphi 2009 makes the Console code much cleaner. It also got a bit faster because of the performance improvements of UnicodeString compared to WideString.

So, while I can understand that not everyone wants to invest the time for the Delphi 2009 conversion, I do not think that adding this compatibility mode would have been a good decision, especially not in the long run.