As many other Delphi bloggers have already written about, today marks the 18th anniversary of the release of Delphi 1. This is a significant achievement given the years of speculation about Delphi's demise, and it certainly has been through some rough times.
However, it genuinely feels like good times again at the moment. So much so that we at Carval have committed to the latest version, and are looking forward to the Delphi mobile version that is in the pipeline.
It does, though, make me realise how long I've been doing this job already. I had a lucky break and was given a project in my final year at Manchester University that used this brand new 16-bit development platform, called Delphi. It didn't take me long to upgrade to Delphi 2, and here I am 18 years later having made a career from it.
Happy birthday, Delphi. Congratulations to those at Embarcadero who are still as involved now as they were on Day 1.
Thursday, 14 February 2013
Thursday, 31 January 2013
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!
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!
Wednesday, 9 January 2013
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.
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.
Tuesday, 16 November 2010
Using CDO to write to Exchange from a Windows Service
Not strictly a Delphi-post this one, but still a programming issue nonetheless.
We have several Windows Services that have the ability to add an entry to people's Outlook Calendars or Task Lists. This cannot be done using Outlook Automation, because that requires Outlook to be accessible to run which it cannot be from a Windows Service. Furthermore, it mandates that Outlook is installed on the PC or Server which is not something we can guarantee.
The alternative I started using years ago was Collaboration Data Objects, CDO, a Microsoft library that basically gives you a great deal of access to the Exchange Server, without ever having to know anything about Outlook, which is, after all, just a client for Exchange Server.
CDO is available in Delphi by simply importing the "Microsoft CDO 1.21 Library" type library.
Despite being complicated to set up (necessarily so due to mailbox security), this works very well, and is what Microsoft use for their Outlook Web Access software. Reading on the subject, I see that Symantec and Blackberry are also users of this API.
Now, Microsoft being Microsoft, CDO has not been on-developed for quite some time, although it continues to work just fine. It is no longer installed as standard on the OS when Outlook (2007 onwards) is installed, but they now allow you to install it yourself by releasing an MSI that installs the CDO and MAPI DLLs.
Microsoft state in their Knowledgebase Article 2028411 that:
The question is, what are developers supposed to use instead of CDO? It fills a gap that the Outlook Object Model cannot fill, namely, use in web applications and Windows Services. It appears they are not providing an alternative, and yet are encouraging developers away from it towards a tool that cannot work unless running as a standard Windows application.
We have several Windows Services that have the ability to add an entry to people's Outlook Calendars or Task Lists. This cannot be done using Outlook Automation, because that requires Outlook to be accessible to run which it cannot be from a Windows Service. Furthermore, it mandates that Outlook is installed on the PC or Server which is not something we can guarantee.
The alternative I started using years ago was Collaboration Data Objects, CDO, a Microsoft library that basically gives you a great deal of access to the Exchange Server, without ever having to know anything about Outlook, which is, after all, just a client for Exchange Server.
CDO is available in Delphi by simply importing the "Microsoft CDO 1.21 Library" type library.
Despite being complicated to set up (necessarily so due to mailbox security), this works very well, and is what Microsoft use for their Outlook Web Access software. Reading on the subject, I see that Symantec and Blackberry are also users of this API.
Now, Microsoft being Microsoft, CDO has not been on-developed for quite some time, although it continues to work just fine. It is no longer installed as standard on the OS when Outlook (2007 onwards) is installed, but they now allow you to install it yourself by releasing an MSI that installs the CDO and MAPI DLLs.
Microsoft state in their Knowledgebase Article 2028411 that:
Programs that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO. Starting with Outlook 2007, the Outlook object model was greatly expanded to provide functionality that was previously available only by using CDO 1.2.1. The Outlook 2010 object model includes some new features to expand on this more...The Outlook object model also works for both 32-bit and 64-bit versions of Outlook. Developers should use the Outlook 2010 object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI.
The question is, what are developers supposed to use instead of CDO? It fills a gap that the Outlook Object Model cannot fill, namely, use in web applications and Windows Services. It appears they are not providing an alternative, and yet are encouraging developers away from it towards a tool that cannot work unless running as a standard Windows application.
Monday, 6 September 2010
Open Letter to Digital Metaphors
I am currently rewriting our standard Crystal Reports (over 250) in ReportBuilder, so that we can standardise on one report writer. I have been so impressed by ReportBuilder during this development process that I felt compelled to write to Digital Metaphors and let them know.
I just wanted to drop you a line to say how continually impressed I am with ReportBuilder. We have been a customer since RB version 4, when we chose it as the report writer that we wanted to embed in our software for end users. This decision came some time after we had already started the software, and so the standard reports we provide are written with Crystal Reports.
I am currently undergoing a 2 month project to eliminate Crystal Reports from our system, which involves rewriting over 250 reports in ReportBuilder. I am about 85% of the way through this project now, and I can only say it has actually been a pleasure, rather than the chore I was expecting it to be. There hasn't been one thing that I haven't been able to reproduce in ReportBuilder, and in the majority of cases, the RB method of doing something is far better.
Of particular importance to us have been RAP, the SQLBuilder class and Autosearch Parameters. The aim has been to totally design these reports so that they are self-sufficient, i.e. there is no Delphi form or code behind them as individual reports. These 3 features have enabled this transition, and I believe that, thanks to your product, we now have superior reports.
We also have the need to modify the query of every report when it runs, in order to add security so that the users only see the subset of data they're allowed to see. This is made so easy by the TdaSQLBuilder class.
With the email and PDF export built-in, we will also be able to achieve one area of functionality we have long strived for: automated, or scheduled, reports. I will now be able to allow users to select a report, set a time for it to run on a regular basis, and ask them to supply any parameters in advance. It can then be printed or emailed overnight, or as required.
Not to mention how powerful the RB Server edition has been; we have been able to offer user-defined web-based reports for our intranet software which has been one of our most successful features to date.
As a software developer, I know that praise is hard to come by and it can be dejecting to just see a long list of problems, such as if you look at the newsgroups. This is why I felt compelled to write and let you know that we regard ReportBuilder as our most valuable third-party add-on for Delphi.
Friday, 13 August 2010
Still alive and still on Delphi 6
I hadn't realised that my last post was January, 6 months has just disappeared. 6 being the magic number, in that we still have not found the time to stop development on our products in order to migrate up to Delphi 2009 that we bought a while back.
Since then, Delphi 2010 passed me by without a great deal of interest, and now I find myself with even less enthusiasm for Delphi2011 XE, there is simply nothing in it that encourages me to upgrade.
(I also can't understand the naming convention. Although David I explained it last week, it isn't a convention that will scale. "X" for heterogeneous, and "E" for Embarcadero. What happens to the next version? It's like Microsoft coming up with Windows 95, 98, ME, 2000, XP, Vista, 7 - absolutely no consistency in the naming convention and if you didn't know which was which, you wouldn't know what order they came in. Maybe that only matters to me.)
In any case, we have taken one decision that will make the Unicode transition to Delphi 2009 easier, and that is to drop our support for Crystal Reports in the next release of our product. We are currently tied to using Crystal Reports 7 (yes, really!) because it was the last version that a stable Crystal VCL for Delphi component was written for. Besides, the latest versions of Crystal Reports have dropped any support for native software developers, only now supporting VS.Net and Eclipse developers.
It does mean that I am having to rewrite over 250 standard reports in our preferred report designer, ReportBuilder from Digital Metaphors. But this product is now well embedded into our software, we provide the designer for users to write their own reports and we can access any part of the report at run-time in order to inject data security before the user sees the final report.
So one less unsupported component out of the way, and with ReportBuilder 12, we can also drop yet another third-party component that did some things that ReportBuilder wasn't able to do previously, but can now.
As a side note, over the past 6 months, I've come to totally rely on the Raize and TMS component sets, to the point now where I use them more than the standard VCL controls. The Raize ones just work well and look so good, and the TMS ones have so much functionality crammed into them; our users are really starting to see the benefit of good interface design.
Our company recently put out a call to customers for product testimonials in order that we could be considered for a software award; one word out of all of the responses pleased me the most about our software: robust.
Since then, Delphi 2010 passed me by without a great deal of interest, and now I find myself with even less enthusiasm for Delphi
(I also can't understand the naming convention. Although David I explained it last week, it isn't a convention that will scale. "X" for heterogeneous, and "E" for Embarcadero. What happens to the next version? It's like Microsoft coming up with Windows 95, 98, ME, 2000, XP, Vista, 7 - absolutely no consistency in the naming convention and if you didn't know which was which, you wouldn't know what order they came in. Maybe that only matters to me.)
In any case, we have taken one decision that will make the Unicode transition to Delphi 2009 easier, and that is to drop our support for Crystal Reports in the next release of our product. We are currently tied to using Crystal Reports 7 (yes, really!) because it was the last version that a stable Crystal VCL for Delphi component was written for. Besides, the latest versions of Crystal Reports have dropped any support for native software developers, only now supporting VS.Net and Eclipse developers.
It does mean that I am having to rewrite over 250 standard reports in our preferred report designer, ReportBuilder from Digital Metaphors. But this product is now well embedded into our software, we provide the designer for users to write their own reports and we can access any part of the report at run-time in order to inject data security before the user sees the final report.
So one less unsupported component out of the way, and with ReportBuilder 12, we can also drop yet another third-party component that did some things that ReportBuilder wasn't able to do previously, but can now.
As a side note, over the past 6 months, I've come to totally rely on the Raize and TMS component sets, to the point now where I use them more than the standard VCL controls. The Raize ones just work well and look so good, and the TMS ones have so much functionality crammed into them; our users are really starting to see the benefit of good interface design.
Our company recently put out a call to customers for product testimonials in order that we could be considered for a software award; one word out of all of the responses pleased me the most about our software: robust.
Tuesday, 26 January 2010
The road to Delphi 2009 - Part 1 (v) revisited
Well that was judicious timing (for once)! Just as we decided to take the plunge and do away with ODBCExpress in favour of dbGo, I had an email from Pieter Myburgh at Korbitec. In it, he stated that the management had rejected the proposal to make ODBCExpress open-source and instead have "end-of-lifed" the project.
Now, Pieter has been nothing but helpful and this decision was out of his hands. But what a strange decision. After his personal email to me, another one followed to other developers which was a bit more definitive:
As you know a few of us here at Korbitec have been pushing to get ODBCExpress open-sourced, since there is no ongoing development, and recent changes in Delphi 2009 of the char & string types to Unicode have made ODBCExpress unusable in its current form in this version of Delphi. The bad news is that open-sourcing ODBCExpress has been rejected by management for various reasons. However the good news is that the latest source code is available for download by all of the existing registered users of ODBCExpress. Furthermore you are allowed to modify the source code in any way for your own purposes, or collaborate with other registered ODBCExpress users to port it to newer versions ofDelphi if needed. So unfortunately this is the end of the road of Korbitec’s involvement with maintaining ODBCExpress.
Pretty much the same message is available on the ODBCExpress website.
It's an odd decision not to open-source it, as TurboPower did so successfully with its VCL component sets all those years ago. They can't make any more money out of it, they're encouraging developers to collaborate and help each other, they're giving away the source code to registered developers who don't already have the source - yet they won't make the source code available to everyone so that the project might live on.
Bit of a two-fingers up to Delphi really. Pretty sad ending to a good set of components.
Now, Pieter has been nothing but helpful and this decision was out of his hands. But what a strange decision. After his personal email to me, another one followed to other developers which was a bit more definitive:
As you know a few of us here at Korbitec have been pushing to get ODBCExpress open-sourced, since there is no ongoing development, and recent changes in Delphi 2009 of the char & string types to Unicode have made ODBCExpress unusable in its current form in this version of Delphi. The bad news is that open-sourcing ODBCExpress has been rejected by management for various reasons. However the good news is that the latest source code is available for download by all of the existing registered users of ODBCExpress. Furthermore you are allowed to modify the source code in any way for your own purposes, or collaborate with other registered ODBCExpress users to port it to newer versions of
Pretty much the same message is available on the ODBCExpress website.
It's an odd decision not to open-source it, as TurboPower did so successfully with its VCL component sets all those years ago. They can't make any more money out of it, they're encouraging developers to collaborate and help each other, they're giving away the source code to registered developers who don't already have the source - yet they won't make the source code available to everyone so that the project might live on.
Bit of a two-fingers up to Delphi really. Pretty sad ending to a good set of components.
Subscribe to:
Posts (Atom)