Migration from Delphi 6 to Delphi XE3

Welcome back! It's been 2 and a half years since I last posted on this blog. Although it is partly down to the usual "too much work" and "kids keep me busy", it's largely because even after all this time, I'm still on Delphi 6(!), and so had nothing new to report. That's right, we never managed to find the time to migrate to Delphi 2009.

Not for much longer though. We've taken the decision that in March/April this year, myself and the development team are going to take the plunge, and finally upgrade from Delphi 6. Not to Delphi 2009 as I originally wrote about though. This time, we're going straight to the very latest version, Delphi XE3.

This has come about not only because our hand has been forced by some of the third-party components we use (TMS Component Pack, ReportBuilder, Raize Components) - none of the new versions of these support Delphi 6 - but also because we're starting to think about mobile development. Delphi XE3 offers decent distributed database architecture with DataSnap which we can make use of to write some terrific companion mobile apps for our software.

It is somewhat of a relief to see that dbGo (ADO) is still well supported with Delphi XE3, vindicating the decision I made a few years ago to switch over to that from ODBCExpress. This will form the largest part of our migration process, as we have to move all existing components over to the dbGo equivalent. However, we have established how to do this without any real complications, and so it will just be more time-consuming than difficult.

Of course, there will still be the Unicode effect that came when Delphi 2009 was released, "breaking" existing code. But this has been well documented by Delphi luminaries such as +Bob Swart, +Marco Cantù and +Cary Jensen, and so this will present no real issues.

The superb ReportBuilder Enterprise by Digital Metaphors stores the database connectivity information within the report file itself, so I have already written a utility that replaces the ODBCExpress details with that of ADO. This will instantly convert our 250 standard reports, as well as the countless reports written using the built-in report writer by users for themselves.

The largest task at hand is converting our "plug-ins". When I first joined the company over 14 years ago, my task was to rewrite the software to convert it from Unix to Windows. There were multiple versions of the software for each customer, based on their bespoke requirements. I vowed this would not be allowed to happen to the Windows version of the software, and so developed the plug-in architecture which allows bespoke functionality to appear within the core software, as if it were standard. To this day it works perfectly, however its success has grown much larger than I ever anticipated, meaning there are now over 100 plug-ins for various customers and other "extra" features that we can provide. Each of these is a separate Delphi project, and so this will be enormously time consuming to migrate these.

But it will be worth it. We will finally be on a development platform that can provide us with "modern" features, whilst giving us opportunities to develop in other areas as well.

I'll keep posting as I come across any interesting areas during the move! I'd love to hear from you if you have done anything similar and have any "gotchas" you'd like to share.

The road to Delphi 2009 - Part 1 (iv)

So it has been a while since I last updated on my progress with the migration from Delphi 6 to Delphi 2009. There's a reason. I'm still on Delphi 6 and I've got nowhere fast with ODBCExpress!

To be fair to its developer, Pieter Myburgh, it isn't his project anymore and he has been very good in keeping in touch with me and letting me know how the open source status is coming along. Very slowly, it would seem. He created a project on SourceForge and that is the only activity there has been. I think legal red tape is giving him a bit of a headache.

I know I'm not the only one really hoping we can get ODBCExpress moved up to Unicode-enabled Delphi 2009. But I'm starting to come under a bit of pressure now to look at alternatives. It is understandable - we paid a lot of money of the new version (as it was then) of Delphi, under my recommendation, only to find we can't use it.

I've looked at changing to dbGo (ADO) or dbExpress, and have participated in some interesting discussions on Stack Overflow about the merits of both. But ultimately, the thought of having to change to the core database connectivity components of 10 years worth of software (including nearly 50 plug-ins) makes me shudder. Not least because we use a great deal of the intricate little details of ODBC and ODBCExpress, which we'd have to find alternatives for - if, indeed, an alternative is available.

On the upside, we would have had to buy Delphi 2009 or 2010 this year anyway, because of Embarcadero's decision to only allow upgrade prices for users of Delphi 2006 and later from 2010.

And also I have got all the other component sets that we use installed in Delphi 2009, and the main application compiles. So small steps are being made.

Bit the bullet: Delphi 2009!

So, I finally bit the bullet and purchased a Delphi upgrade, to D2009. The offer was too tempting and I have started to become frustrated with being left too far behind with Delphi 6.

Thanks to one of the distributors in the UK, Grey Matter, we got the D2009 upgrade for 20% off. This was a promotion they were running for those who didn't want to take advantage of June's "Buy Delphi and get RAD Studio free" promotion. Apart from a slight, but only curious interest in Delphi Prism, there wasn't enough to tempt me, in these economic times, to not take the 20% off instead.

And so I will chronicle my journey to take our 10 year old product, written in Delphi 5 then Delphi 6, to Delphi 2009. The challenges I forsee are more to do with API headers written for some of the hardware devices (clocking terminals) that we support with our T&A product, but time will tell.

To start with, it will be a case of getting the main part of the software converted and see how that goes. I have the latest versions of all our third-party products such as Raize Components 5, TMS Component Pack, ReportBuilder Server & Enterprise 11 and TsiLang Translation.

Could have some fun with older components like the Crystal Reports VCL component for Delphi (for Crystal Reports 7). Anyone got any experience with that?

Should be "interesting"...!

Real-world tools #6: Raize Components

Despite the claims that I don't like to have reams of different component packs installed in Delphi, there is often a case that a particular component set just has that killer component that demands its use. I've been aware of Raize Components for years but never made the leap of using them because I'd committed myself to TMS and JEDI, and that was enough for me.

Late last year, I attended a UK Developer's Group workshop with Ray Konopka, on UI design. It was an excellent couple of days and Ray, as I've seen him do in conference presentations, managed to not so subtley slip in references in Raize Components and CodeSite. And now I can see why... I was about the only one in the room that wasn't using Raize Components, and now I am converted.

So why take the decision to add yet another component set? Well, it was a trade-off for me. If Raize Components could do everything that I was using from an existing component pack, then I'd go with it. So I trialled it and two things stood out for me.

1. The TRzBitBtn supports XP/Vista themes where appropriate and uses the ImageList for its image property, not the Glyph property. This meant that I could use it to replace the TJvImgBtn from the JVCL, which frankly was the only component I was using from it regularly.

In fact, almost every component supports XP/Vista themes, and almost everything has the ability to use system colours, Office colours or custom gradients. The results are stunning. TMS offer this with their AdvOffice components too but I've had issues with it on Delphi 6 and Bruno told me in an email that they were looking to drop support for Delphi 6, and so they weren't going to be resolved for me. (But rest assured, the Styler mechanism in TMS is absolutely brilliant and a doddle to set up).

2. Almost every visual Raize control has a Transparent property. This is exactly what I have been looking for, for some time now, as we move into form design with gradient colours. Having a transparent panel, page control, group box, radio group box, etc, means that I can use gradient colours on a form and still have groups & panels.

Once I'd seen those two I was convinced, but it got better. The RzToolBar & RzPageControl replacements are so far superior to the standard VCL controls (and solve all the bugs I was having with those controls, which are just wrappers of the Windows Common Controls); the design-time editors that are installed as part of the Raize Component pack are so helpful that when you use an IDE that doesn't have them, you're left frustrated; and the edit boxes with the buttons actually as part of them mean that I no longer have to have a separate edit box and BitBtn next to it.

I could go on and there are similar components out there in other component packs, but what makes the difference is the standard way they look and behave, and the superb documentation that is lacking from almost all other third-party packs out there.

So JEDI has almost gone for me. With all due respect to the JEDI developers, who put in so much time and good, hard work, but there's just too many components for me to handle, and they're all a little bit different because of the nature of the open-source community. I say almost gone, because there are a few components that are actually irreplaceable, like the TJvWizard. Once you've used it, you'll never go back to a form with a PageControl on it.

What I also like about the Raize Components is that they are simple to upgrade. When a new release comes out, I don't even have to uninstall packages or worry about losing settings; the installer just works, updates my files and allows me to fire up Delphi and move on. Which takes the headache out of getting the latest version.

Ray takes what he talks about in his UI Design talk and implements it into a quality product, that adheres to his design principles and offers you controls that behave as you'd expect them to. And as Ray himself says, that's rule #1 of good UI design: it behaves as the user expects it to.

Real-world tools #5: IP*Works! SSL

It's been a while and for that I apologise, although perhaps many of you are grateful that it's taken 2 months for me to post. Usual stuff, I know you're all up against the same things. Deadlines, massive development schedules, testing, meetings... you know, real-world stuff.

I wanted to get back into this by explaining briefly why I chose IP*Works! from /n software. It came about because part of our payroll product needed to consume a web service written by (or for) the UK's revenue department, HMRC.

Version 1 of this web service was more basic than its successor, and as a result the standard SOAP Web Services tools that came with Delphi 6 were sufficient to do the job. Good old Delphi does the trick again, out of the box.

A year or so after version 1, the whole HMRC service was redesigned and so version 2 of the web service was born. Whilst it remained on the SOAP platform (due to a unanimous decision from the software developers that had to ultimately consume it), they introduced an element into version 2 that Delphi 6 did not handle: SOAP headers.

At this point, I had 3 options. Option 1 was to move to Delphi 7 in which support for SOAP headers was introduced as standard. Option 2 was to try the Indy Soap which also claimed to support SOAP headers. Option 3 was to buy a third-party product.

My preferred option was number 2, not least because it enabled me to stay with the version of Delphi I was on and we were already using the awesome Indy components for other HTTP, FTP and SMTP work. However, I failed 100% to even get this code to compile despite the help of the indy-soap-public Yahoo group. I decided this was going to be too much of a battle to even get started and so investigated option 1, upgrading Delphi.

This was a tricky decision, because although Delphi 7 would have given me what I needed, Delphi 2005 had been released by then. I felt that it would be ridiculous to spend all the time and effort moving from D6 to D7, along with upgrading all the third-party tools, etc, when it wasn't even the latest release. But I couldn't justify at that time a move to D2005 because it was taking a knock amongst its users, the cost was much higher and, crucially, I couldn't get a definitive answer on whether the SOAP stuff from D6/7 would work in D2005.

After coming to the disappointing decision that I wasn't going to upgrade from Delphi 6 at this time, and with development time running out, option 3 remained: a third-party tool. This was my least preferred for reasons I have explained in earlier posts: I don't like tabs and tabs of third-party components when I could have used a standard one. However, sometimes the guys who write these third-party tools are experts and sell stacks of their product for good reason, and IP*Works! fell under this category.

I had to buy the more expensive SSL version because the HMRC web service was run on a secure server but this wasn't a real issue. It essentially meant that I got all of the same components as with the non-SSL version but with the option to use secure communications or not.

IP*Works! SSL V6 Delphi Edition (still the current release) is a terrific product and I got the secure web service running within days, including all the extra SOAP header bits that I'd not been able to do with D6. If I hadn't have had such success with the other Indy components (HTTP, FTP, SMTP, etc) then I would have used the IP*Works! ones. It turns out that it was an expensive suite for just using 1 component for one utility, but it is a killer utility that pushed us ahead of the competition for a while.

When (not if) I finally do makr the jump to D2007 or RAD Studio 2007, it's likely I'll try and redo this utility to use Delphi's in-built SOAP objects because that it always my goal, to get back to as few third-party ties as possible. But for now the IP*Works! components are solid, robust, well designed and well documented and this is a purchase I didn't regret.

Although, an asterisk and an exclamation mark in a product's name drives me crazy!