Delphi 6 to XE3: SOAP and IP*Works SSL

Although we have not officially begun the migration phase yet from Delphi 6 to XE3, I have started installing our third-party component packs to ensure they are all working.

One of our products requires communication with the HMRC, the UK's tax man (equivalent of the IRS in the United States). This communication is done using SOAP, using a secure address. Originally, I had planned on writing this using the native SOAP components introduced in Delphi 6. However, the specification from HMRC showed that the SOAP envelope had to contain a SOAP header.

The HTTPRIO in D6 did not have a SOAPHeaders property, and so we made the decision (rightly or wrongly) to buy the IP*Works SSL component pack (version 6) from /n Software. Although expensive for the one component we needed it for (TipsSOAPS), this contained everything we needed and we were able to complete the project.

This component pack is now up to version 9, and the only upgrade path is for the prior version (i.e. version 8). Given that we have Version 6 which doesn't work in Delphi XE3, it looked like we would need to purchase it again. But at $899, I wanted to see if there was another way!

Now don't get me wrong, it is a sophisticated and well supported component suite and I have no issue with the company or the product itself. But I am not prepared to pay full price for a product I already bought once, when that price is about the same as I paid for Delphi.

My first thought was to try to the Delphi Edition of IP*Works that is available to registered users of Delphi XE3. So I downloaded and installed it. I had a sneaking suspicion that this would not allow me to do what I needed, because there is a separate component pack for non-secure and secure communications. And indeed, the TipwSOAP component would not allow me to consume a web service over https:

Personally I think charging $899 to handle SSL URLs is a bit of a con.

So, knowing that Delphi introduced support for SOAP headers in Delphi 7, I knew that the only reason we had bought this product in the first place was no longer a problem. So I set about writing a prototype to see if I could implement the same functionality using native Delphi components.

And I have! So +1 for Delphi XE3. I just saved the company $899, and shed another third-party component pack at the same time (and that makes me very happy).

I should also point out that this is the first time I have really, properly used a Delphi IDE other than Delphi 6, and it was an huge pleasure. Very fast and productive. So far, so good!

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 #3: TMS Components

I'm not a fan of component packs. As I said before, I'm a conservative developer who (rightly or wrongly) believes that the less third-party tools I can get away with using the better, purely for future-proofing purposes. When a third-party vendor I already use provides a component similar to some other component I found somewhere, I'll switch to that one to reduce my dependencies. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency again. But it's inevitable that eventually you do have to make use of the terrific toolsets out there because they're there to enhance your applications.

Some aren't so terrific.

For as long as I can remember, Woll2Woll Software ran the same advert in all of the published Delphi magazines with exactly the same screenshot of their InfoPower Suite of components. They have achieved the unenviable by managing to show a product that looks no better in 2007 as it did in 1997. Who in their right mind would buy this product when the screen shots look like this? Is this demo showing the best capability of their component suite?

To be fair, because of this I have never downloaded and trialled this package, and it may be that many of you are using it and couldn't live without it. If so, tell us about it, because I wouldn't go near this looking like a Windows 3.1 application and maybe I'm missing out.

On the other hand, TMS Software and its founder Bruno Fierens have produced some outstanding Delphi components for many many years. I have been using them before there was even a component pack, instead each component could be used and bought individually. The main draw back then was that for non-commercial use, the components were free, without source. I understand this is still the case. But of course I am using them for commercial use, plus I always support other software vendors, and so I have purchased the Component Pack which, quite simply, is outstanding. Especially when you get full source code too.

For a staggeringly small €175 (just under £120 or $235 US), the pack contains over 275 components and a year of free updates when they're released, as well as direct email support. Again, I'm not here to promote someone else's business but I am prepared to acknowledge good work and good value for money when I come across it.

In fact it is great work. What started out as a series of Advanced components to replace the Delphi standard components has grown into a business that has seen TMS win award after accolade. The components are never left alone, they're constantly being improved and updated; whilst new components get added all the time to try and keep up with the style that Microsoft have decided to take on with each release of Office.

Whilst many may not care about this (I personally don't use them), and Nick Hodges recently said that CodeGear isn't going to try and play catch up with MS any more, to me it shows that Bruno and co are on the ball, always trying to be first to give you that new "look" should you want to keep your products looking in keeping with what Microsoft call the new standard. This isn't playing catch-up at the expense of the other components, this is simply good sense on their part. I'll talk about the moving-Microsoft-standard another day!

TMS also did themselves a lot of favours by supporting Intraweb almost as soon as it came out. Their Intraweb Pack contains over 70 components to enhance Intraweb applications in the same way they enhance Windows ones. We used them here for a while when we had a browser-based application and they achieved more than we could have done with Intraweb alone. Not only that but they've branched out into ASP.Net, CLX and PocketPC component sets too (although you can't use these with Delphi for .NET as it doesn't support the Compact Framework yet, if ever).

The component pack was runner-up for Best VCL Component Set in the 2002-2004 Delphi Informant Magazine awards, second each time to the ExpressPack by DeveloperExpress. I haven't used these components either but they do look good, and I suspect there is an even split between you regarding which one of these sets you use. Although to my eye they're not necessarily direct competitors as the DevExpress toolset is more about the visual whereas TMS also provides a lot of non-visual components to do donkey-work for you.

At any rate, at least both of them know how to market their products well.

Update: Milan & Paul have made valid points about the documentation and it has been remiss of me to not talk about that in any of my Real-World tools series so far. The documentation in TMS is poor, although sadly this isn't unusual in what I call professional components. ReportBuilder now has excellent documentation and for ODBCExpress, it is acceptable in that the Delphi Help is pretty much all you need. TMS have made the same mistake as Borland did with BDS2005/2006, and to some extent with Delphi 2007 for Win32: that is, not document all of the properties, methods and events. I'm not sure what is worse. TMS omitting them all together or CodeGear having the stub in the help file with no words.

As all of us developers know, documentation comes last but there are so many good tools out there now that can write your documentation for you if you have well-structure code commenting. The JEDI documentation is half missing too but that's free and open source so forgiveable and, in part, up to us to help them with that. It's not forgiveable when you've paid for the components and the technical support falls a bit short (although I've had some good feedback from Bruno via the groups and email in the past).

Real-world tools #1: ReportBuilder

There are some third-party components I use that I'm still not sure about, but that are so embedded in my work now that the thought of changing them isn't all that appealing. ReportBuilder (RB), by Digital Metaphors, isn't one of those. This, it turns out, is one of the best decisions I ever made. My experience below is based on version 10 Enterprise.

I think I first read about it in the Delphi Informant magazine about eight or nine years ago when an article was written that was a semi-tutorial and review at the same time. One of the nice things for me is that this is all that Digital Metaphors do: a report writer for Delphi. The product has now been around for a long time and during the time that Delphi Informant was running, ReportBuilder won Best Reporting Tool and Best Product of the Year for several years running.

There are a few really good reporting solutions out there, all of which are such a pleasure to use after using QuickReports! I guess a lot of Delphi developers use Rave Reports since it started being bundled with Delphi, but by the time this had happened, I was already ensconced in ReportBuilder.

For a start, it is written fantastically well. If you ever needed convincing that object-oriented code was the way forward but and never looked at the Delphi VCL, you should see ReportBuilder's code. It's simply the most extensible, accessible and flexible code I have ever come across. There isn't a part of the software that you can't change, get to, manhandle or simply read. As each version progresses and they add new features, they actually go back and make the existing features easier to use as well by exposing more properties.

For me, the best example of this is the report query itself (if you're not attaching to a dataset which, of course, you can). Once you have built up your query (using either the standard Query Wizard or Designer, or your own custom Query Wizard or Designer), you can then access the query as an object. And each part of that query is an object too, so you have the Criteria object and the Join object, etc. You can access this at run-time so you can amend the query to suit your needs just before the report runs, or at least see the query that has been generated for you. Simply use the object properties and methods to change the query and the SQL text itself is updated. This is simply genius and so much easier than having to manually trawl through the query text in order to add a table and its join at a later stage.

As I mentioned, any of the wizards or dialogs can be descended from to make your own class, which you then register with RB and use those instead.

And this mechanism is what allows it to communicate with any database class out there. Of course you're given default support for the BDE, text files and "Just-In-Time" data sources, but because they all descend from a base class, you can use any others on the market. I myself wrote ones for Titan Access and Titan SQLAnywhere by Reggatta Systems when we used those components (more on that another day), and I've had some input on the class for ODBCExpress. Once compiled, RB can connect to your third-party database interface and you'll never think about it again.

Similarly, the new email feature in version 10 supports MAPI and Indy 9 and 10 from different classes, but if you use another SMTP facility then a new class can be derived to support it.

Like Delphi, RB comes in different flavours for different prices. Standard is the entry level system which only allows you to write reports; the next step up, Professional, allows you to include the designer within your software to offer a report-writing solution. Enterprise adds RAP capability which I'll come to below, and Server Edition adds web server support for displaying your reports on the web.

RAP was formally introduced I think in about version 6, although it had been available in beta stage for some versions prior to that. Report Application Pascal is basically a mini-Delphi within the report writer, whereby you can add code to events of the report or any of its components - just like a TForm and the components you drop on it. With each new version, the RAP language expands allowing more and more control over the look and data output of your report. This is so powerful that I can't imagine how I ever wrote a report without it. If you use Crystal Reports, it's similar to the formula language used within it. And like Crystal, you can extend it if a method or class you want isn't in it.

This isn't meant to be a sales pitch for Digital Metaphors so I won't go on to list all of its features, but I should commend them for their excellent technical support via the newsgroups. There are groups for the different sections of report writing and often they will contact you directly if you have raised an issue so you can sort it out between you before the newsgroup is given the solution.

No matter what happens, this is one toolset that actually drives which version of Delphi we use, and as ever they are supporting the latest version of Delphi almost as soon as anyone.

Personally, I believe ReportBuilder is about as good as third-party components get. We recently made significant database changes to our main software in order that we could move forward with bigger and better features. This wasn't an easy change, it took almost 6 months to get the software working as it was before the changes, and of course it was going to affect every user-defined report written using our software, over which we have no control (that's the point after all, isn't it?). So how did we get all these user reports to play nicely with the massive database restructure? We wrote a conversion utility that changed the SQL of the reports, using RB's SQLBuilder object. How easy did that make it? Well let's just say that I'd still be manually changing them now if that wasn't available. As it was, we never received a single user report by email to convert; we could see the reports as code, change the code as necessary, and save it back.

That alone was worth the price.

Tools of the real world

I should explain what it is I do with Delphi every day, which will maybe give a background as to why I've become what I consider a conservative developer. Conservative, that is, in terms of what software we use. The company I have worked for for the past 9 years develops three main products (payroll, HR and Time & Attendance, combined as a suite), written for Windows using Delphi.

Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.

Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.

I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.

It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.

It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:

• ReportBuilder 10 (Digital Metaphors)
• ODBCExpress (Korbitec)
• TMS Component Pack (TMS Software)
• IP*Works! SSL (/n Software)
• Indy 9 (Nevrona)
• JEDI VCL
• Crystal Reports VCL