A few people have reviewed this book already but for various personal and work commitments, reasons, I've been unable to review the book until now.
It's been many years since a really innovative Delphi book came out that was worth taking a look at. Delphi Product Manager +Marco Cantù's annual book is always an excellent source of up-to-date reference, and Coding in Delphi by the former Product Manager +Nick Hodges was a worthy giveaway to those who purchased recent versions of Delphi.
Delphi Cookbook was written by an author I'd not come across in the Delphi community before, +Daniele Teti. It reminds me of some of the O'Reilly books I have read in the past that, although they don't assume a certain level of knowledge and explain things well enough for beginners, you get much more out of them if you do have some language experience. Indeed, Daniele explains up front in the lengthy preface that it is not aimed at beginners.
The book contains 50 "recipes" covering not only VCL Windows projects, but also cross-platform development using FireMonkey, for Windows, Mac, iOS and Android. It was written alongside Delphi XE6 and so already is one version out of date, but it is not much of an issue in this case because the recipes work much the same across all versions (although XE4 is the minimum required for the FireMonkey cross-platform code).
The first chapter, Delphi Basics, is a real eclectic mix of topics, ranging from the relatively new VCL Styles to parsing XML and JSON, from Windows Services to really old topics such as associating file extensions. These are simple to follow and some, especially the XML and JSON topics, are useful building blocks for later on.
On the whole, the recipes are enjoyable to follow and Daniele has done a good job with the downloadable examples so you can see the ideas in action when compiling them in Delphi.
There is a slightly odd flow to the book; for example, chapter 2 discusses reasonably low-level concepts like RTTI, anaonymous methods and class helpers; this is followed by chapter 3 which discusses styles in FireMonkey, and chapter 4 which then goes low-level again with multi-threading using TMonitor and TEvent.
Probably the most useful chapter for me, and possibly for many now Delphi has entered the mobile marketplace, is chapter 5, which covers writing the server-side application or service, for your remote applications to communicate with. This is neatly followed by a chapter on the mobile basics, many of which are already covered by the examples and demos provided with Delphi. However, chapter 7 also takes you further into Android and iOS platform specifics.
I like Daniele's informal style which sets the tone that this book is really about exploration and fun, rather than about following a "recipe" to the letter. He is often honest in his appraisal of a Delphi feature, which is refreshing, but it shines through that this was a labour of love about a development environment about which he, and his prospective readers, are passionate.
Without the advent of the mobile development in Delphi, I don't think this book would have taught much new to a seasoned developer. But there is plenty of well-explained content in here for everyone to have something to learn. At the very low price it is being offered for, it's a good go-to book to have in your library.
Friday, 19 December 2014
Friday, 17 October 2014
Delphi development update
Hi everyone,
I can't believe it's been over a year since my last posting. My last post was having a moan about the cost of Delphi XE5, coming from XE4. Well, as many pointed out to me, the Software Assurance plan was the way to go and I'm now happily running on Delphi XE7 and enjoying being on the latest releases of Delphi as and when they emerge.
I know the whole SA/Recharge issue is a hot topic amongst Delphi developers, but I've covered that already and, as a successful business which uses Delphi heavily, the SA plan is actually a reasonable price to pay for the benefits we get from each new version of Delphi. So let's leave that discussion to the forums, for now.
I really wanted to mention 2 things today.
Firstly, using Delphi XE7, we have had our first app successfully submitted to the iOS App Store. I can't say too much about it yet because we want to give our customers the first details. But I have to say that I submitted the app to Apple 3 weeks ago, thinking the whole process would take months, knowing how difficult I've heard it is to get an app approved. Within less than 2 weeks, my app was approved, first time, and is currently in the store. Written entirely using out-of-the-box Delphi, on the FireUI framework. Communicating to a Datasnap Server written also entirely in Delphi. This is terrific for us and we have been able to re-use so much existing code for the app that would have had to be rewritten had we chosen another mobile development framework.
Secondly, I have a copy of the new Delphi Cookbook by +Daniele Teti which I have just begun and will post a review of within the next month. It's written in an informal style making it an easy read, and all of the example code is available to download if you buy the book.
Having used and evangelised Delphi for the past 20 years, I thought I knew everything there is to know, but there are some nice topics that I've encountered already that have explained something new or different, and it's always good to learn.
Happy coding.
I can't believe it's been over a year since my last posting. My last post was having a moan about the cost of Delphi XE5, coming from XE4. Well, as many pointed out to me, the Software Assurance plan was the way to go and I'm now happily running on Delphi XE7 and enjoying being on the latest releases of Delphi as and when they emerge.
I know the whole SA/Recharge issue is a hot topic amongst Delphi developers, but I've covered that already and, as a successful business which uses Delphi heavily, the SA plan is actually a reasonable price to pay for the benefits we get from each new version of Delphi. So let's leave that discussion to the forums, for now.
I really wanted to mention 2 things today.
Firstly, using Delphi XE7, we have had our first app successfully submitted to the iOS App Store. I can't say too much about it yet because we want to give our customers the first details. But I have to say that I submitted the app to Apple 3 weeks ago, thinking the whole process would take months, knowing how difficult I've heard it is to get an app approved. Within less than 2 weeks, my app was approved, first time, and is currently in the store. Written entirely using out-of-the-box Delphi, on the FireUI framework. Communicating to a Datasnap Server written also entirely in Delphi. This is terrific for us and we have been able to re-use so much existing code for the app that would have had to be rewritten had we chosen another mobile development framework.
Secondly, I have a copy of the new Delphi Cookbook by +Daniele Teti which I have just begun and will post a review of within the next month. It's written in an informal style making it an easy read, and all of the example code is available to download if you buy the book.
Having used and evangelised Delphi for the past 20 years, I thought I knew everything there is to know, but there are some nice topics that I've encountered already that have explained something new or different, and it's always good to learn.
Happy coding.
Wednesday, 18 September 2013
The rising cost of being a Delphi developer
If you review my previous postings over the past few years, you'll notice that I'm overwhelmingly positive about Delphi, Embarcadero and the quality of the software I can release because of them.
I subscribe to Delphi Feeds, as any self respecting Delphi developer should, and I read a lot of articles where opinion varies wildly. Differences of opinion are important, no matter what the subject. From the MVPs who can only write positively about Delphi and RAD Studio, to Jolyon Smith who is probably the most vociferous voice regarding the direction of Delphi and Embarcadero (and whose opinion I almost never agree with but would fight for his right to express it).
However, for the first time recently, I agreed with one of his posts. And I wasn't alone. And other Delphi writers were also expressing the same opinion: New releases of Delphi/RAD Studio are becoming prohibitively expensive.
Now, we write enterprise level software and the cost of Delphi is not significant in terms of our turnover. However, Delphi markets itself not only to enterprise ISVs, but to anyone who wants to write software simple and effectively. It does this well, but recently I feel that it's only us ISVs who can afford to keep buying the increasingly regular Delphi releases. They don't do updates any more, they're full scale releases.
They're good releases too. Personally, I use XE3 and XE4 Enterprise for our Windows desktop software, and for the iOS mobile app that we sell to complement it. Given that I had purchased a licence for XE3 Enterprise in 2012 for £800, the cost to upgrade to XE4 was in the region of £400. This caused concern in blogs at the time: an upgrade for 50% of the cost of the last version. But for us, the layout was well worth it for the effort that had gone into the iOS framework. And I was on the beta testing panel for that, and believe me, they made a lot of fixes before release.
And now, XE5 is released, offering us Android development as well. And the quote from my local reseller? £903.24 + VAT (£1083.60). Or from Embarcadero's online store? £892 + VAT (£1061). For an upgrade! This beggars belief. As The Delphi Hater's article says:
I did receive an email a few days later offering me 20% if purchased directly from Embarcadero Developer Direct, but that's still £850, effectively knocking off the VAT.
And why do two of those links from above quote the upgrade price in the US as $499? And some suggest that the upgrade from Delphi XE3 to XE4 only cost them $49? Is the UK/Europe being ripped off again?
Note that I've had the Enterprise versions all along, I've not had to jump up a level. I've also never (so far) taken out the support & maintenance contract, which makes me a bloody idiot. :)
Worse still, the ADUG article has this to say about the changes to Delphi for iOS for iOS7:
If this is true, this is an outrage. All along, we've been led to believe by Embarcadero that new styles would be made available for iOS7 when the time comes, there was never any suggestion that this would come at the cost of a new version of Delphi.
So for the first time, I find myself deliberately not purchasing the software I have staked my career on, and which I need to deliver Android apps using the codebase and experience I've built up over 15 years. Some may say that I am finally seeing what they've always been saying, to which I only partially agree. They have to make their money back somewhere, but you can't charge full price for an upgrade.
I'm interested to hear what prices other people have been quoted, both for new and upgrade licences?
Perhaps Embarcadero should let me buy a support licence, seeing as I purchased XE4 in the past few months, which would then, in theory, give me XE5?
I should re-iterate: for new users, sure it's expensive, but you're buying an IDE and 20+ years of experience, to develop on multiple platforms. I'm not unhappy with that price. But for an upgrade to cost so much, when I'm upgrading from a version I purchased earlier in the same year? No.
I subscribe to Delphi Feeds, as any self respecting Delphi developer should, and I read a lot of articles where opinion varies wildly. Differences of opinion are important, no matter what the subject. From the MVPs who can only write positively about Delphi and RAD Studio, to Jolyon Smith who is probably the most vociferous voice regarding the direction of Delphi and Embarcadero (and whose opinion I almost never agree with but would fight for his right to express it).
However, for the first time recently, I agreed with one of his posts. And I wasn't alone. And other Delphi writers were also expressing the same opinion: New releases of Delphi/RAD Studio are becoming prohibitively expensive.
- Te Waka o Pascal - Not so Special Upgrade Pricing for XE5
- Turbu Tech - Delphi XE5: Promised Android support not included!
- TPersistent.com - XE5 “Special” Upgrade a Bargain?
- Australian Delphi User Group Members - Don’t be a bloody idiot
- Delphi Haters' Blog - The Delphi XE5 bait & switch promotion
Now, we write enterprise level software and the cost of Delphi is not significant in terms of our turnover. However, Delphi markets itself not only to enterprise ISVs, but to anyone who wants to write software simple and effectively. It does this well, but recently I feel that it's only us ISVs who can afford to keep buying the increasingly regular Delphi releases. They don't do updates any more, they're full scale releases.
They're good releases too. Personally, I use XE3 and XE4 Enterprise for our Windows desktop software, and for the iOS mobile app that we sell to complement it. Given that I had purchased a licence for XE3 Enterprise in 2012 for £800, the cost to upgrade to XE4 was in the region of £400. This caused concern in blogs at the time: an upgrade for 50% of the cost of the last version. But for us, the layout was well worth it for the effort that had gone into the iOS framework. And I was on the beta testing panel for that, and believe me, they made a lot of fixes before release.
And now, XE5 is released, offering us Android development as well. And the quote from my local reseller? £903.24 + VAT (£1083.60). Or from Embarcadero's online store? £892 + VAT (£1061). For an upgrade! This beggars belief. As The Delphi Hater's article says:
The logic is - If you buy XE5 you get XE4 for free. If you buy XE4 and didn't get SA, you are screwed.
I did receive an email a few days later offering me 20% if purchased directly from Embarcadero Developer Direct, but that's still £850, effectively knocking off the VAT.
And why do two of those links from above quote the upgrade price in the US as $499? And some suggest that the upgrade from Delphi XE3 to XE4 only cost them $49? Is the UK/Europe being ripped off again?
Note that I've had the Enterprise versions all along, I've not had to jump up a level. I've also never (so far) taken out the support & maintenance contract, which makes me a bloody idiot. :)
Worse still, the ADUG article has this to say about the changes to Delphi for iOS for iOS7:
Statements today from an Embarcadero representative on a public mailing list indicated that the soon to be released update providing support for iOS7 will be for XE5 only, XE4 users will not receive it.
If this is true, this is an outrage. All along, we've been led to believe by Embarcadero that new styles would be made available for iOS7 when the time comes, there was never any suggestion that this would come at the cost of a new version of Delphi.
So for the first time, I find myself deliberately not purchasing the software I have staked my career on, and which I need to deliver Android apps using the codebase and experience I've built up over 15 years. Some may say that I am finally seeing what they've always been saying, to which I only partially agree. They have to make their money back somewhere, but you can't charge full price for an upgrade.
I'm interested to hear what prices other people have been quoted, both for new and upgrade licences?
Perhaps Embarcadero should let me buy a support licence, seeing as I purchased XE4 in the past few months, which would then, in theory, give me XE5?
I should re-iterate: for new users, sure it's expensive, but you're buying an IDE and 20+ years of experience, to develop on multiple platforms. I'm not unhappy with that price. But for an upgrade to cost so much, when I'm upgrading from a version I purchased earlier in the same year? No.
Wednesday, 17 April 2013
Initial thoughts on Delphi XE4 - iOS development
So the main thrust of my blog entries in the past few years have been about how I've wanted to make the leap from Delphi 6 to the latest version, currently Delphi XE3. As you may have read so far, we're now there and it has brought us so many benefits that I have promised I'll post about later.
In the meantime, because of purchasing XE3, I've also been allowed to take part in the beta testing of Delphi XE4, which many are referring to as Delphi for iOS.
I must mention that I have specifically given permission to discuss this by Embarcadero, and that any thing I raise now is still under pre-release and subject to change. This also isn't a critique of what is there or what is missing, more an overview to help answer any questions you may have about what is coming.
A point that confused me before taking part in the Beta was "is this going to be just an iOS development tool, or is the next version of Delphi"? The answer to that is clearly the latter. This product will be launched as RAD Studio XE4/Delphi XE4/C++ Builder XE4, and will be a complete version of your favourite development tool. It still allows for Win32, Win64, Mac and Metropolis projects as XE3 does, with the new addition of iOS Mobile projects, using Firemonkey.
When you start a new project, you are presented with an on-screen representation of the iPhone canvas.
On this screenshot as an example, you can see a standard TButton, TListBox and TToolbar, all of which are styled with Firemonkey to appear as native iPhone controls. The IDE allows you to rotate this view, as well as select different form types so you can develop for iPhone 5 and iPad.
This appears on the XCode iOS Simulator as:
My demo application has a TClientDataSet which is used to store local settings, and uses DataSnap client components to communicate over the internet to a DataSnap server running in my organisation. All of this technology has been available in Delphi for some time but it is crucial that this is working for enterprise iOS apps, and it is working great.
Unlike Delphi XE2 which used the Free Pascal compiler to generate the iOS code, XE4 handles everything natively. You still, of course, need an intel-based Mac running Lion or Mountain Lion, and like with Mac OS development, Embarcadero provide the Platform Assistant (PAServer) which runs on the Mac. Your Delphi project will communicate with the PAServer on the Mac (as set in Project Options, see screenshot below), which in turn communicates with XCode via the command line to deploy your project in the iOS Simulator or onto your iOS Device.
If you have been using any recent version of Delphi or RAD Studio then the IDE is as familiar as ever, which makes this such a great opportunity for us long-term Delphi users to start writing iOS apps. A great job has been made in getting "styles" together for the iOS controls, so that your TListbox can be styled in a variety of different native and expected ways. The TButton, too, has dozens of style options that comes with recognisable images so that your app can appear as native as you need it to be. Of course, if you want to eschew the standard styling and go your own way, Firemonkey gives you the freedom to do that.
As each pre-release version has been issued, so have more and more demos, and the documentation is improving, so there is plenty of good sample code to show you how to use the camera, the Share features, accelerometer, compass, etc.
There is plenty more to talk about this exciting new version of Delphi, but we are still in the pre-release phase and I'm sure there's more to come.
In the meantime, because of purchasing XE3, I've also been allowed to take part in the beta testing of Delphi XE4, which many are referring to as Delphi for iOS.
I must mention that I have specifically given permission to discuss this by Embarcadero, and that any thing I raise now is still under pre-release and subject to change. This also isn't a critique of what is there or what is missing, more an overview to help answer any questions you may have about what is coming.
A point that confused me before taking part in the Beta was "is this going to be just an iOS development tool, or is the next version of Delphi"? The answer to that is clearly the latter. This product will be launched as RAD Studio XE4/Delphi XE4/C++ Builder XE4, and will be a complete version of your favourite development tool. It still allows for Win32, Win64, Mac and Metropolis projects as XE3 does, with the new addition of iOS Mobile projects, using Firemonkey.
When you start a new project, you are presented with an on-screen representation of the iPhone canvas.
 |
| iOS project in Delphi XE4 |
On this screenshot as an example, you can see a standard TButton, TListBox and TToolbar, all of which are styled with Firemonkey to appear as native iPhone controls. The IDE allows you to rotate this view, as well as select different form types so you can develop for iPhone 5 and iPad.
This appears on the XCode iOS Simulator as:
 |
| Project on the XCode iOS Simulator |
My demo application has a TClientDataSet which is used to store local settings, and uses DataSnap client components to communicate over the internet to a DataSnap server running in my organisation. All of this technology has been available in Delphi for some time but it is crucial that this is working for enterprise iOS apps, and it is working great.
Unlike Delphi XE2 which used the Free Pascal compiler to generate the iOS code, XE4 handles everything natively. You still, of course, need an intel-based Mac running Lion or Mountain Lion, and like with Mac OS development, Embarcadero provide the Platform Assistant (PAServer) which runs on the Mac. Your Delphi project will communicate with the PAServer on the Mac (as set in Project Options, see screenshot below), which in turn communicates with XCode via the command line to deploy your project in the iOS Simulator or onto your iOS Device.
If you have been using any recent version of Delphi or RAD Studio then the IDE is as familiar as ever, which makes this such a great opportunity for us long-term Delphi users to start writing iOS apps. A great job has been made in getting "styles" together for the iOS controls, so that your TListbox can be styled in a variety of different native and expected ways. The TButton, too, has dozens of style options that comes with recognisable images so that your app can appear as native as you need it to be. Of course, if you want to eschew the standard styling and go your own way, Firemonkey gives you the freedom to do that.
As each pre-release version has been issued, so have more and more demos, and the documentation is improving, so there is plenty of good sample code to show you how to use the camera, the Share features, accelerometer, compass, etc.
There is plenty more to talk about this exciting new version of Delphi, but we are still in the pre-release phase and I'm sure there's more to come.
Wednesday, 27 March 2013
Migration to XE3: Almost there
Two months back, when I was replacing all of data layer components in Delphi 6, in preparation for the move to Delphi XE3, I never imagined that part would actually be the most time consuming. I am writing today having fully completed the software migration over to XE3. (There are still some utilities and bespoke projects to be done but these are small projects that take little time and wouldn't affect the launch of a new version of our standard package).
We have still to entirely functionally test the software for any run-time issues and unexpected behaviour changes, but our entire software codebase is now ported to XE3 and running well. The bottom line is this: it was much easier than I thought it would be.
As I mentioned in my previous post on the migration to ADO, the longest part of this process has been writing out the old components and replacing them with the dbGo ones. Obviously there is a good case here for better data abstraction, but time was limited and we had to get the job done so we did it the manual and long way. Maybe that's something we can work on over the coming years but for now, the job is done and the results are good.
Most of the run-time issues we've seen are actually database-related, so nothing to do with XE3, but more to do with subtle differences in the way ADO and ODBC work, as well as syntactical differences in the components.
As for the XE3 compilation, the bulk of what we encountered was to do with the Unicode breaking changes from Delphi 2009. This was largely covered in several white papers by Marco Cantu, Cary Jensen, Bob Swart, etc when Delphi 2009 was released. My colleague and I read the papers and agreed on the recommended approach that we move to full Unicode support, rather than replace String with AnsiString, PChar with PAnsiChar, etc.
Although our software is almost exclusively UK based (because of its nature), and the fact that the data we have to submit to HMRC (the UK government tax agency) is only allowed to contain ASCII characters, we found that it was easier for us to move forward with the native Delphi types than to try and maintain the older Ansi types.
The only exception to this, where I really had to put my brain into gear, was for some API headers that I had written in Delphi for some older hardware DLLs. The hardware communication stopped working with Unicode types, so I switched those back to Ansi types and everything worked as it did before. Also, we have some units that implement some well known encryption routines (SHA-1, Base64, MD5), and these all needed attention to prevent them from using Unicode.
Here is a summary of the things we came across most often:
I was also able to get rid of the manual manifest files I had created to allow Windows theme support, as this has been a project option for a long time in Delphi, but obviously not way back in D6.
I'd like to talk about the IDE and performance changes but I will save these for another post. But for now, I'm delighted with how well the migration has gone and the results we have. If you're thinking about doing it, but had the same reservations I me, then I can now say from experience that it isn't as bad as you think and it's worth the effort.
We have still to entirely functionally test the software for any run-time issues and unexpected behaviour changes, but our entire software codebase is now ported to XE3 and running well. The bottom line is this: it was much easier than I thought it would be.
As I mentioned in my previous post on the migration to ADO, the longest part of this process has been writing out the old components and replacing them with the dbGo ones. Obviously there is a good case here for better data abstraction, but time was limited and we had to get the job done so we did it the manual and long way. Maybe that's something we can work on over the coming years but for now, the job is done and the results are good.
Most of the run-time issues we've seen are actually database-related, so nothing to do with XE3, but more to do with subtle differences in the way ADO and ODBC work, as well as syntactical differences in the components.
As for the XE3 compilation, the bulk of what we encountered was to do with the Unicode breaking changes from Delphi 2009. This was largely covered in several white papers by Marco Cantu, Cary Jensen, Bob Swart, etc when Delphi 2009 was released. My colleague and I read the papers and agreed on the recommended approach that we move to full Unicode support, rather than replace String with AnsiString, PChar with PAnsiChar, etc.
Although our software is almost exclusively UK based (because of its nature), and the fact that the data we have to submit to HMRC (the UK government tax agency) is only allowed to contain ASCII characters, we found that it was easier for us to move forward with the native Delphi types than to try and maintain the older Ansi types.
The only exception to this, where I really had to put my brain into gear, was for some API headers that I had written in Delphi for some older hardware DLLs. The hardware communication stopped working with Unicode types, so I switched those back to Ansi types and everything worked as it did before. Also, we have some units that implement some well known encryption routines (SHA-1, Base64, MD5), and these all needed attention to prevent them from using Unicode.
Here is a summary of the things we came across most often:
- Implicit string conversion warnings.
90% of the time this was simply because different variable types were being used. In almost all cases for me personally, it was the use of the ShortString type that raised this warning, and so I made the decision to just do away with ShortString all together and always use String. - WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit.
Another compiler warning well reported in the Unicode conversion white papers, this is simply as case of changing the syntax of testing for a Char in a set of Chars. - Syntax error using local settings constants.
Having made much use of constants such as ShortDateFormat, ShortDayNames, etc, these now have to be prefix with the FormatSettings global variable. - [dcc32 Hint] Inline function 'TFont.GetStyle' has not been expanded because unit 'System.UITypes' is not specified in USES list.
The name of the class and method often changes, but this compiler hint is always resolved by following the instruction: add UITypes to the unit's Uses clause. - Version Info and Release v Debug.
This one really caught us out and I wasn't aware of it until we switched to XE3. Firstly, projects now have separate Release and Debug build configurations, which means any project options you have need to be set individually.
Not a problem for the most part, but the Delphi 6 project file's (.dpr) VersionInfo doesn't migrate across correctly into XE3. The Language Locale reverted back to English (United States), where we had previously had it set to English (United Kingdom). Also, the information only came across for the Release configuration, so needed to be redone in the Debug configuration. We use the information in here for checking which modules can be loaded at run-time so it was important that it was set correctly in both configurations.
Personally, I don't like having to switch to Debug mode into order to be able to set breakpoints and step through code, and then have to remember to set it back to Release mode for the final build. I guess you have the option to set both configurations to use the same Compiler settings, but this would add unncessary debug information to the compiled release executable, so I can see the point of having 2 options. I suppose it is just a case of having to get used to a new routine.
I was also able to get rid of the manual manifest files I had created to allow Windows theme support, as this has been a project option for a long time in Delphi, but obviously not way back in D6.
I'd like to talk about the IDE and performance changes but I will save these for another post. But for now, I'm delighted with how well the migration has gone and the results we have. If you're thinking about doing it, but had the same reservations I me, then I can now say from experience that it isn't as bad as you think and it's worth the effort.
Tuesday, 5 March 2013
Migration to XE3: ADO complete
If you've been following this (often tortuous) path of how we are going to migrate our 14 year old software from Delphi 6 to XE3, you'll know that our only real stumbling block was the fact we were using the now defunct ODBCExpress database component set. We needed to move to a different tool that was supported by XE3, and so we finally decided upon the dbGo ADO components that have been native with Delphi since Delphi 5.
It is with great satisfaction that I can report we have now moved all of the standard code over to the ADO components. There are still some bespoke utilities that we will come to later, but for now the standard software is up and running using ADO. It took us a little over two weeks of solid work to code out the old component set, and this was all done in Delphi 6 so that we could get ourselves to a point where, in theory, everything was working the same as before.
I'm delighted with the speed improvement we've seen in database access. I'm not sure whether this is because ADO is an improvement over ODBC, or the drivers are better, or whether the ADO components are more effective than the ODBCExpress components were. Probably a bit of everything.
It's kind of funny timing that just as we finished this refactoring, Embarcadero announced the purchase of AnyDac (now called FireDac). A few years ago when I first blogged about needing to move away from ODBCExpress, a few correspondents recommended AnyDac. I've heard nothing but good things about it, but ultimately I wanted to get away from a non-native third-party component set which is why we opted for dbGo. I'm pleased with this decision still, but I certainly would have given AnyDac a closer look had I known that it would become standard issue by the time we got to XE3.
I'd like to take the opportunity to thank my colleague Andrew for his collaboration on this task. I've been putting this off for a while now but having another pair of (safe) hands has given us the confidence to go for it, and Andrew has effortlessly ploughed through the same tedium as I have in order to get us to where we need to go.
So now, the next step is to open the code in XE3 and work through the Unicode warnings. I'll keep you posted.
It is with great satisfaction that I can report we have now moved all of the standard code over to the ADO components. There are still some bespoke utilities that we will come to later, but for now the standard software is up and running using ADO. It took us a little over two weeks of solid work to code out the old component set, and this was all done in Delphi 6 so that we could get ourselves to a point where, in theory, everything was working the same as before.
I'm delighted with the speed improvement we've seen in database access. I'm not sure whether this is because ADO is an improvement over ODBC, or the drivers are better, or whether the ADO components are more effective than the ODBCExpress components were. Probably a bit of everything.
It's kind of funny timing that just as we finished this refactoring, Embarcadero announced the purchase of AnyDac (now called FireDac). A few years ago when I first blogged about needing to move away from ODBCExpress, a few correspondents recommended AnyDac. I've heard nothing but good things about it, but ultimately I wanted to get away from a non-native third-party component set which is why we opted for dbGo. I'm pleased with this decision still, but I certainly would have given AnyDac a closer look had I known that it would become standard issue by the time we got to XE3.
I'd like to take the opportunity to thank my colleague Andrew for his collaboration on this task. I've been putting this off for a while now but having another pair of (safe) hands has given us the confidence to go for it, and Andrew has effortlessly ploughed through the same tedium as I have in order to get us to where we need to go.
So now, the next step is to open the code in XE3 and work through the Unicode warnings. I'll keep you posted.
Thursday, 14 February 2013
18 Years of Delphi
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.
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, 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.
Thursday, 21 January 2010
The curious case of dead Delphi
You don't have to look very far for people asking the question "Is Delphi Dead?". StackOverflow had a recent question on it, and Delphi developer JamieI recently created a website to answer the question succinctly.
OK, so it was a darling of the 90s and these days it isn't as high profile as it used to be - .NET hurt Delphi badly because it took Delphi's edge away. However, isn't it part of the job of software professionals to keep up to date with what programming languages and tools and available?
I use Delphi exclusively, yet I still know all about the recent versions of Ruby on Rails, C#, PHP, Java, VB.Net, ASP.Net (etc etc) because I make it my job to know about them. I don't read in technical detail about the merits of each and what the new versions provide, but I'm aware of the other tools available in my industry because they are important to the future of software development.
So if I wasn't a Delphi developer, I'd still know that Delphi 2010 was recently launched, that Delphi had a new owner and that the future wasn't over.
Tim Anderson recently posted a blog about the future of Microsoft Access, and he was asked in a comment what development platform he uses, to which he answered "Visual Studio or Delphi". The reply astounded me:
I used Delphi many years ago, I did not realise it was still going.
Now, this was from someone who called themselves "Freelance Access Developer" which may explain a lot about his or her scope of knowledge of the software industry, but surely if you used to use Delphi, you'd notice in passing a headline about the new version coming out or a recent buyout of the company.
Or maybe I just read too much.
OK, so it was a darling of the 90s and these days it isn't as high profile as it used to be - .NET hurt Delphi badly because it took Delphi's edge away. However, isn't it part of the job of software professionals to keep up to date with what programming languages and tools and available?
I use Delphi exclusively, yet I still know all about the recent versions of Ruby on Rails, C#, PHP, Java, VB.Net, ASP.Net (etc etc) because I make it my job to know about them. I don't read in technical detail about the merits of each and what the new versions provide, but I'm aware of the other tools available in my industry because they are important to the future of software development.
So if I wasn't a Delphi developer, I'd still know that Delphi 2010 was recently launched, that Delphi had a new owner and that the future wasn't over.
Tim Anderson recently posted a blog about the future of Microsoft Access, and he was asked in a comment what development platform he uses, to which he answered "Visual Studio or Delphi". The reply astounded me:
I used Delphi many years ago, I did not realise it was still going.
Now, this was from someone who called themselves "Freelance Access Developer" which may explain a lot about his or her scope of knowledge of the software industry, but surely if you used to use Delphi, you'd notice in passing a headline about the new version coming out or a recent buyout of the company.
Or maybe I just read too much.
Tuesday, 19 January 2010
The road to Delphi 2009 - Part 1 (v)
A new year and time to make a decision about how we are going to move our ten year old codebase from Delphi 6 up to Delphi 2009. If you've followed my other posts in this "road to Delphi 2009" thread then you'll know that I hit a stumbling block when migrating a third-party component, ODBCExpress. This is a third-party database connectivity component that was well written, well documented and had good reviews and articles in Delphi Informant (which dates it a bit for those who remember that magazine).
At the time we chose it, our product was based on the Access database and we were looking to add SQL Server support, so we chose it as a good option to handle any database type. I explained this back in June 2007.
Unfortunately, the product was no longer actively developed from Delphi 2006 and despite help from its main developer to at least get it compiled into Delphi 2009, it didn't work properly thanks to all the Unicode changes.
Seeing as we bought Delphi 2009 in June 2009 and haven't migrated to it yet, a decision has been made. We are going to move all the code away from ODBCExpress, and to the dbGo ADO components provided as standard with Delphi (from Delphi 5 through to the current Delphi 2010).
Presciently, in June 2007, I also said this:
I've thought about moving to one of those bundled Delphi offerings in order to save myself the worry should ODBCExpress go tilt. But I haven't...because the database architectures offered with Delphi keep changing and I'm not sure I want to run the risk of changing everything over only to have it "deprecated" like the BDE.
Well the dbGo components are still going strong and they made the effort to Unicode-enable them for Delphi 2009, so I'm classing this as a low-risk option.
I wrote some test programs using the ODBCExpress components and then migrated it to ADO to see what conversion issues I'd have. I made notes and it wasn't as bad as I thought. I can now do everything I could do with the ODBCExpress components, even if I have had to write a function that does what a component used to do. If anything, it has been an interesting exercise in the back-end of SQL Server.
What was particularly pleasurable was doing all the work in Delphi 6 and then simply recompiling it in Delphi 2009 to see what happened. The answer: it compiled and ran just as it did in Delphi 6 (give or take a few string cast warnings in my own code which is part of the Unicode migration, and expected). Perfect.
For those who may ask why I'm not going for dbExpress instead (which is also standard with Delphi and developed by CodeGear/Embarcadero), it was a couple of things. It was initially my preferred choice but the extra DataSetProvider/ClientDataSet layer required to use it visually gave me the creeps, and I've been reading some frightening problems that people are having with it with Delphi 2010 and SQL Server. Plus the architecture of dbGo more closely matches that of ODBCExpress, facilitating the migration.
So now we have a path, a light at the end of the tunnel. It's not going to be pretty, and I know it will be tedious, but it will be another third-party component set that I can drop which, as I said in another posting in June 2007:
that the less third-party tools I can get away with using the better, purely for future-proofing purposes. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency.
I'm now looking forward to the journey again.
At the time we chose it, our product was based on the Access database and we were looking to add SQL Server support, so we chose it as a good option to handle any database type. I explained this back in June 2007.
Unfortunately, the product was no longer actively developed from Delphi 2006 and despite help from its main developer to at least get it compiled into Delphi 2009, it didn't work properly thanks to all the Unicode changes.
Seeing as we bought Delphi 2009 in June 2009 and haven't migrated to it yet, a decision has been made. We are going to move all the code away from ODBCExpress, and to the dbGo ADO components provided as standard with Delphi (from Delphi 5 through to the current Delphi 2010).
Presciently, in June 2007, I also said this:
I've thought about moving to one of those bundled Delphi offerings in order to save myself the worry should ODBCExpress go tilt. But I haven't...because the database architectures offered with Delphi keep changing and I'm not sure I want to run the risk of changing everything over only to have it "deprecated" like the BDE.
Well the dbGo components are still going strong and they made the effort to Unicode-enable them for Delphi 2009, so I'm classing this as a low-risk option.
I wrote some test programs using the ODBCExpress components and then migrated it to ADO to see what conversion issues I'd have. I made notes and it wasn't as bad as I thought. I can now do everything I could do with the ODBCExpress components, even if I have had to write a function that does what a component used to do. If anything, it has been an interesting exercise in the back-end of SQL Server.
What was particularly pleasurable was doing all the work in Delphi 6 and then simply recompiling it in Delphi 2009 to see what happened. The answer: it compiled and ran just as it did in Delphi 6 (give or take a few string cast warnings in my own code which is part of the Unicode migration, and expected). Perfect.
For those who may ask why I'm not going for dbExpress instead (which is also standard with Delphi and developed by CodeGear/Embarcadero), it was a couple of things. It was initially my preferred choice but the extra DataSetProvider/ClientDataSet layer required to use it visually gave me the creeps, and I've been reading some frightening problems that people are having with it with Delphi 2010 and SQL Server. Plus the architecture of dbGo more closely matches that of ODBCExpress, facilitating the migration.
So now we have a path, a light at the end of the tunnel. It's not going to be pretty, and I know it will be tedious, but it will be another third-party component set that I can drop which, as I said in another posting in June 2007:
that the less third-party tools I can get away with using the better, purely for future-proofing purposes. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency.
I'm now looking forward to the journey again.
Friday, 18 December 2009
The Register: Ten years of .NET - Did Microsoft deliver?
The always excellent Tim Anderson, writing for the always excellent The Register, has put together a nice article on the relative success and failure of .NET as a platform and as a Java-killer.
I've made it clear in the past that I'm no fan of .NET and I don't see any clear benefit to our industry by its introduction. This paragraph sums it up nicely:
A long-standing gripe is that Microsoft itself has been slow to adopt .NET. "It will be the framework that Microsoft itself uses going forward" Microsoft's Tony Goodhew told TechEd in 2000. The company, though, has continued to use native code and C++ as the primary development platform for its crown jewels, Windows and Office. COM has never gone away, and .NET developers who want to use new Windows 7 APIs, for example, have to use an interop library to do so.
Seeing as CodeGear/Embarcadero came to the same conclusion when they decided to stop playing catch-up with .NET in Delphi, I can justify my decision never to take our software into the .NET arena.
I've made it clear in the past that I'm no fan of .NET and I don't see any clear benefit to our industry by its introduction. This paragraph sums it up nicely:
A long-standing gripe is that Microsoft itself has been slow to adopt .NET. "It will be the framework that Microsoft itself uses going forward" Microsoft's Tony Goodhew told TechEd in 2000. The company, though, has continued to use native code and C++ as the primary development platform for its crown jewels, Windows and Office. COM has never gone away, and .NET developers who want to use new Windows 7 APIs, for example, have to use an interop library to do so.
Seeing as CodeGear/Embarcadero came to the same conclusion when they decided to stop playing catch-up with .NET in Delphi, I can justify my decision never to take our software into the .NET arena.
Thursday, 26 November 2009
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.
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.
Thursday, 9 July 2009
The road to Delphi 2009 - Part 1 (iii)
Still calling this Part 1 (Act 3) as I'm not actively pushing anything forward until I've overcome the ODBCExpress hurdle. I've had some positive steps forward with this.
I have been in regular contact with Pieter Myburg, its original author. Even though he is no longer actively developing it, he has very helpfully made some changes to 3 files that allow the packages to compile and install into Delphi 2009.
Even more helpfully, he has agreed to Open Source it and is looking for moderators. I have agreed to help (as has another user this morning) but we need more, as I can't honestly say with full confidence what I know what I'm doing with the code! I don't want to give out his email address on a blog but the newsgroup for ODBCExpress is news.korbitec.com.
So now I can connect my data and view it. I've already noticed that nvarchar fields (SQL Server) display with non-printable characters so that is my first area of investigation.
I have also come across another peculiar one. If I connect within the IDE, everything displays in a DBGrid. If I run the executable, when the database connects, the debugger pops up and shows me the CPU Window on ntdll.DbgBreakPoint. This used to happen to me in Delphi 6 when I pressed F12 in my software, which I understand was a bug left in the IDE. However, this happens when the database connects so I'm guessing it must be something in code.Whether that is ODBCExpress code or native VCL code, I'm unsure.
Slowly moving forward.
I have been in regular contact with Pieter Myburg, its original author. Even though he is no longer actively developing it, he has very helpfully made some changes to 3 files that allow the packages to compile and install into Delphi 2009.
Even more helpfully, he has agreed to Open Source it and is looking for moderators. I have agreed to help (as has another user this morning) but we need more, as I can't honestly say with full confidence what I know what I'm doing with the code! I don't want to give out his email address on a blog but the newsgroup for ODBCExpress is news.korbitec.com.
So now I can connect my data and view it. I've already noticed that nvarchar fields (SQL Server) display with non-printable characters so that is my first area of investigation.
I have also come across another peculiar one. If I connect within the IDE, everything displays in a DBGrid. If I run the executable, when the database connects, the debugger pops up and shows me the CPU Window on ntdll.DbgBreakPoint. This used to happen to me in Delphi 6 when I pressed F12 in my software, which I understand was a bug left in the IDE. However, this happens when the database connects so I'm guessing it must be something in code.Whether that is ODBCExpress code or native VCL code, I'm unsure.
Slowly moving forward.
Wednesday, 1 July 2009
The road to Delphi 2009 - Part 1 (reprise)
So I haven't really got any further yet because I'm waiting to hear back from the author of ODBCExpress whether or not he will look to upgrade the packages for Delphi 2009. He's emailed to say he is "looking into it". From the newsgroup I can see I'm not the only one crossing my fingers.
If he doesn't then D2009 will be put on hold while I port 10 years of software to another database connectivity tool, so I can even open it in D2009. If he does, well then we'll be all set for moving onwards.
After I posted about having less screen real-estate, I found that using the push-pins gave me my entire screen. Nice touch. Those palettes now float into view if I need them, otherwise they float away. Very nice.
If he doesn't then D2009 will be put on hold while I port 10 years of software to another database connectivity tool, so I can even open it in D2009. If he does, well then we'll be all set for moving onwards.
After I posted about having less screen real-estate, I found that using the push-pins gave me my entire screen. Nice touch. Those palettes now float into view if I need them, otherwise they float away. Very nice.
Thursday, 25 June 2009
The road to Delphi 2009 - Part 1
OK, so I started with the easy stuff. Installing third-party components.
Raize Components - Check
TMS Component Pack - Check
ReportBuilder Enterprise/Server - Check
OK, these were easy because they were designed for Delphi 2009.
ODBCExpress - Oh. Well, according to its lead developer Pieter Myburg on the support newsgroup, "we have stopped active development of ODBCExpress, and we won't be porting it to future versions of Delphi ourselves".
The last support was for Delphi 2006 which, as I understand, compiles fine in Delphi 2007 as that was a non-breaking release. But not Delphi 2009, oh no. So if anyone out there has any experience with bringing this component set up to Delphi 2009, I would love to hear from you. Without this, we're stumped. It'd be a case of going back through 10 years of software and rewriting it to use dbExpress or ADOExpress. And I seriously don't think we can afford that time.
By the way, bearing in mind I have come from Delphi 6 and have only seen screenshots of the IDE from Delphi 2005 onwards, I really like the IDE. Although I seem to have less code editing space because of all the other (really very useful) palettes that surround it.
Raize Components - Check
TMS Component Pack - Check
ReportBuilder Enterprise/Server - Check
OK, these were easy because they were designed for Delphi 2009.
ODBCExpress - Oh. Well, according to its lead developer Pieter Myburg on the support newsgroup, "we have stopped active development of ODBCExpress, and we won't be porting it to future versions of Delphi ourselves".
The last support was for Delphi 2006 which, as I understand, compiles fine in Delphi 2007 as that was a non-breaking release. But not Delphi 2009, oh no. So if anyone out there has any experience with bringing this component set up to Delphi 2009, I would love to hear from you. Without this, we're stumped. It'd be a case of going back through 10 years of software and rewriting it to use dbExpress or ADOExpress. And I seriously don't think we can afford that time.
By the way, bearing in mind I have come from Delphi 6 and have only seen screenshots of the IDE from Delphi 2005 onwards, I really like the IDE. Although I seem to have less code editing space because of all the other (really very useful) palettes that surround it.
Subscribe to:
Posts (Atom)