For as long as there has been Delphi, there has been Project JEDI: Joint Endeavour of Delphi Innovators (or Endeavor if you're Stateside). Initially it was created in order to write API header conversions for Delphi that weren't provided as standard. APIs such as DirectX, ODBC, MAPI, TAPI and Winsock were written and offered up for free with full source code - this was a labour of love and community, not money. It is Open source, distributed under the MPL 1.1 License. Furthermore, extensions were added to the standard headers that had been provided with Delphi, thus exposing more of Windows' capabilities to Delphi developers.
Soon this gave birth to the JCL, the JEDI Code Library. This was a massive set of utilties and classes that could be used, such as algorithms, conversions and literally hundreds of functions designed to make complex jobs easier. Instead of trying to get to grips with MAPI.pas and sending a mail, why not just call JclSimpleSendMail instead? Just going through the contents page on the help, you get an idea of just how much is available. In fact, there's so many that you just don't know where to begin but it's a good place to start looking if you need some complex string search routine or array sort.
But if the JCL is large then the JVCL (JEDI Visual Component Library) is simply enormous. Across 39 tabs, over 500 visual & non-visual components are installed ranging from improved replacements to standard Delphi components to wizards, gauges and trivial animated clocks and dice.
I said in my post on the TMS Component Pack that I'm not a fan of installing component packs and even though I've known about JEDI for as long as I've worked with Delphi, I only installed it early last year. It has come to the point where it isn't just a messy collection of components thrown together any more, it's a well-thought out and organised collection with "something for everyone", although largely I suspect you won't use 75% of them.
Early versions of the JVCL just had all the components that volunteers had written and submitted bundled together, with little documentation and no organistion. Along the way, they stripped out duplicates and integrated it with the JCL so that code reuse was the norm, not an accident.
Documentation is by their own admission "far from complete", as described in the help file overview: "Because of the size of JEDI-VCL and the fact that writing help takes a lot of time, the help file is currently far from complete, the main reason being that too much work has to be done by just a few people". The help is also available on-line at homepages.borland.com/jedi/jedihelp/ which is great because it is searchable. It also means that you can have a look though the help to see what is in there before deciding whether you want to take the plunge with it.
That said about the documentation, I've seen worse! Usually the stub is there added automatically by the documentation software and just needs padding out. But as several people commented with TMS, because you have the source, you can often go in and see for yourself how to use a method or how to set a property that isn't documented. And unlike TMS, you're actually encouraged to change what might be wrong and submit it back to the team.
There is also an online bug tracker at homepages.borland.com/jedi/issuetracker/main_page.php which uses the Mantis bug tracking system. I don't know who the team is behind it, but it is effective and well maintained, with issues being updated every day.
What you have to remember is that this is free software written and maintained by volunteers for no other gain than to improve the Delphi landscape and perhaps a small sense of personal satisfaction that one gets from seeing their name as part of a large project. And so they should because without all of those people who have contributed even a line of code to the source or the help, the JCL and JVCL simply wouldn't be a viable alternative to the commercial toolsets.
Often once you've installed a component package, you leave it because the installation was a nightmare and you're just glad you've got your IDE stable again - not going through that again! Well, the team behind the JCL and JVCL have obviously been burnt by that too because the installer is simply one of the best I have used on any commercial or non-commercial third-party component. Although it is really best to manually remove any existing installations of JEDI first and really make sure the files are deleted, once that is done then the detailed installer wizard makes putting the new version back on a breeze. You can choose what level of installation you want and the JVCL installer checks to make sure you have a high enough version of the JCL before continuing. I doubt this was easy work but it was worth it because I'm actually prepared to keep up to date with the releases.
This isn't a flawless product though, but I cannot bring myself to criticise a package that hasn't cost me anything and that has cost so many people a lot of their free time and expertise. I now regularly use their code and components; sometimes TMS doesn't have a replacement for a particular component and JEDI does; I'm happy to use these two interchangeably.
Bearing in mind that I am still on Delphi 6, I especially use the TjvImgBtn component which is a replacement for the Delphi TBitBtn. Any of you who have your software themed for XP and Vista will know that the Delphi TButton themes nicely but the TBitBtn and TSpeedButton don't. Although there's a little inconsistency in the JEDI button components, in that some theme and some don't, once I found the JvImgBtn I never looked back. In fact I went through all the software I wrote in the last 8 years and replaced SpeedButtons and BitBtns with this component. Furthermore, it doesn't use the Glyph property but it uses an ImageList and has an ImageIndex property. This has reduced my file sizes greatly, although I used to use an ImageList myself and assign the Glyph property at run-time - but all that code has gone now.
I defy you to install it and then not find useful components. You have to be prepared that it will add nearly 40 new tabs to your component palette and increase the loading and closing time of Delphi. But personally I believe this is a trade-off worth taking and the JEDI toolset has finally come of age. Free doesn't have to mean poor quality.
Friday 29 June 2007
Wednesday 27 June 2007
Real-world tools #3: TMS Components
I'm not a fan of component packs. As I said before, I'm a conservative developer who (rightly or wrongly) believes that the less third-party tools I can get away with using the better, purely for future-proofing purposes. When a third-party vendor I already use provides a component similar to some other component I found somewhere, I'll switch to that one to reduce my dependencies. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency again. But it's inevitable that eventually you do have to make use of the terrific toolsets out there because they're there to enhance your applications.
Some aren't so terrific.
For as long as I can remember, Woll2Woll Software ran the same
advert in all of the published Delphi magazines with exactly the same screenshot of their InfoPower Suite of components. They have achieved the unenviable by managing to show a product that looks no better in 2007 as it did in 1997. Who in their right mind would buy this product when the screen shots look like this? Is this demo showing the best capability of their component suite?
To be fair, because of this I have never downloaded and trialled this package, and it may be that many of you are using it and couldn't live without it. If so, tell us about it, because I wouldn't go near this looking like a Windows 3.1 application and maybe I'm missing out.
On the other hand, TMS Software and its founder Bruno Fierens have produced some outstanding Delphi components for many many years. I have been using them before there was even a component pack, instead each component could be used and bought individually. The main draw back then was that for non-commercial use, the components were free, without source. I understand this is still the case. But of course I am using them for commercial use, plus I always support other software vendors, and so I have purchased the Component Pack which, quite simply, is outstanding. Especially when you get full source code too.
For a staggeringly small €175 (just under £120 or $235 US), the pack contains over 275 components and a year of free updates when they're released, as well as direct email support. Again, I'm not here to promote someone else's business but I am prepared to acknowledge good work and good value for money when I come across it.
In fact it is great work. What started out as a series of Advanced components to replace the Delphi standard components has grown into a business that has seen TMS win award after accolade. The components are never left alone, they're constantly being improved and updated; whilst new components get added all the time to try and keep up with the style that Microsoft have decided to take on with each release of Office.
Whilst many may not care about this (I personally don't use them), and Nick Hodges recently said that CodeGear isn't going to try and play catch up with MS any more, to me it shows that Bruno and co are on the ball, always trying to be first to give you that new "look" should you want to keep your products looking in keeping with what Microsoft call the new standard. This isn't playing catch-up at the expense of the other components, this is simply good sense on their part. I'll talk about the moving-Microsoft-standard another day!
TMS also did themselves a lot of favours by supporting Intraweb almost as soon as it came out. Their Intraweb Pack contains over 70 components to enhance Intraweb applications in the same way they enhance Windows ones. We used them here for a while when we had a browser-based application and they achieved more than we could have done with Intraweb alone. Not only that but they've branched out into ASP.Net, CLX and PocketPC component sets too (although you can't use these with Delphi for .NET as it doesn't support the Compact Framework yet, if ever).
The component pack was runner-up for Best VCL Component Set in the 2002-2004 Delphi Informant Magazine awards, second each time to the ExpressPack by DeveloperExpress. I haven't used these components either but they do look good, and I suspect there is an even split between you regarding which one of these sets you use. Although to my eye they're not necessarily direct competitors as the DevExpress toolset is more about the visual whereas TMS also provides a lot of non-visual components to do donkey-work for you.
At any rate, at least both of them know how to market their products well.
Update: Milan & Paul have made valid points about the documentation and it has been remiss of me to not talk about that in any of my Real-World tools series so far. The documentation in TMS is poor, although sadly this isn't unusual in what I call professional components. ReportBuilder now has excellent documentation and for ODBCExpress, it is acceptable in that the Delphi Help is pretty much all you need. TMS have made the same mistake as Borland did with BDS2005/2006, and to some extent with Delphi 2007 for Win32: that is, not document all of the properties, methods and events. I'm not sure what is worse. TMS omitting them all together or CodeGear having the stub in the help file with no words.
As all of us developers know, documentation comes last but there are so many good tools out there now that can write your documentation for you if you have well-structure code commenting. The JEDI documentation is half missing too but that's free and open source so forgiveable and, in part, up to us to help them with that. It's not forgiveable when you've paid for the components and the technical support falls a bit short (although I've had some good feedback from Bruno via the groups and email in the past).
Some aren't so terrific.
For as long as I can remember, Woll2Woll Software ran the same
advert in all of the published Delphi magazines with exactly the same screenshot of their InfoPower Suite of components. They have achieved the unenviable by managing to show a product that looks no better in 2007 as it did in 1997. Who in their right mind would buy this product when the screen shots look like this? Is this demo showing the best capability of their component suite?To be fair, because of this I have never downloaded and trialled this package, and it may be that many of you are using it and couldn't live without it. If so, tell us about it, because I wouldn't go near this looking like a Windows 3.1 application and maybe I'm missing out.
On the other hand, TMS Software and its founder Bruno Fierens have produced some outstanding Delphi components for many many years. I have been using them before there was even a component pack, instead each component could be used and bought individually. The main draw back then was that for non-commercial use, the components were free, without source. I understand this is still the case. But of course I am using them for commercial use, plus I always support other software vendors, and so I have purchased the Component Pack which, quite simply, is outstanding. Especially when you get full source code too.
For a staggeringly small €175 (just under £120 or $235 US), the pack contains over 275 components and a year of free updates when they're released, as well as direct email support. Again, I'm not here to promote someone else's business but I am prepared to acknowledge good work and good value for money when I come across it.In fact it is great work. What started out as a series of Advanced components to replace the Delphi standard components has grown into a business that has seen TMS win award after accolade. The components are never left alone, they're constantly being improved and updated; whilst new components get added all the time to try and keep up with the style that Microsoft have decided to take on with each release of Office.
Whilst many may not care about this (I personally don't use them), and Nick Hodges recently said that CodeGear isn't going to try and play catch up with MS any more, to me it shows that Bruno and co are on the ball, always trying to be first to give you that new "look" should you want to keep your products looking in keeping with what Microsoft call the new standard. This isn't playing catch-up at the expense of the other components, this is simply good sense on their part. I'll talk about the moving-Microsoft-standard another day!
TMS also did themselves a lot of favours by supporting Intraweb almost as soon as it came out. Their Intraweb Pack contains over 70 components to enhance Intraweb applications in the same way they enhance Windows ones. We used them here for a while when we had a browser-based application and they achieved more than we could have done with Intraweb alone. Not only that but they've branched out into ASP.Net, CLX and PocketPC component sets too (although you can't use these with Delphi for .NET as it doesn't support the Compact Framework yet, if ever).
The component pack was runner-up for Best VCL Component Set in the 2002-2004 Delphi Informant Magazine awards, second each time to the ExpressPack by DeveloperExpress. I haven't used these components either but they do look good, and I suspect there is an even split between you regarding which one of these sets you use. Although to my eye they're not necessarily direct competitors as the DevExpress toolset is more about the visual whereas TMS also provides a lot of non-visual components to do donkey-work for you.
At any rate, at least both of them know how to market their products well.
Update: Milan & Paul have made valid points about the documentation and it has been remiss of me to not talk about that in any of my Real-World tools series so far. The documentation in TMS is poor, although sadly this isn't unusual in what I call professional components. ReportBuilder now has excellent documentation and for ODBCExpress, it is acceptable in that the Delphi Help is pretty much all you need. TMS have made the same mistake as Borland did with BDS2005/2006, and to some extent with Delphi 2007 for Win32: that is, not document all of the properties, methods and events. I'm not sure what is worse. TMS omitting them all together or CodeGear having the stub in the help file with no words.
As all of us developers know, documentation comes last but there are so many good tools out there now that can write your documentation for you if you have well-structure code commenting. The JEDI documentation is half missing too but that's free and open source so forgiveable and, in part, up to us to help them with that. It's not forgiveable when you've paid for the components and the technical support falls a bit short (although I've had some good feedback from Bruno via the groups and email in the past).
Tuesday 26 June 2007
Windows time change
When I mentioned yesterday about time zones, it reminded me of an issue I came across a few years ago with the Windows WM_TIMECHANGE message.
Whenever the time is changed on Windows, the WM_TIMECHANGE message is broadcast for any applications to handle if they wish. This was something that was extremely useful to us for our Time & Attendance software because it meant, in theory, that if the time changed on the server that was connected to all of the clocking terminals (on which employees swipe their badges), we would receive the Windows message and send out a time change to the terminals immediately.
This worked really well while I was changing the time on the PC manually; the WM_TIMECHANGE message was issued and our software was issuing out the new time to the terminals.
What this was really designed for though was when the clocks go forward and back, between BST (British Summer Time) and GMT. I knew Windows automatically changed the time on the PC as long as the regional settings were correct, and so I wanted to be able to tap into this and have the terminals updated to the new time as soon as the clock change occured.
But guess what... Windows doesn't issue a WM_TIMECHANGE message when it changes the time for daylight savings. Now that's consistency...
Whenever the time is changed on Windows, the WM_TIMECHANGE message is broadcast for any applications to handle if they wish. This was something that was extremely useful to us for our Time & Attendance software because it meant, in theory, that if the time changed on the server that was connected to all of the clocking terminals (on which employees swipe their badges), we would receive the Windows message and send out a time change to the terminals immediately.
This worked really well while I was changing the time on the PC manually; the WM_TIMECHANGE message was issued and our software was issuing out the new time to the terminals.
What this was really designed for though was when the clocks go forward and back, between BST (British Summer Time) and GMT. I knew Windows automatically changed the time on the PC as long as the regional settings were correct, and so I wanted to be able to tap into this and have the terminals updated to the new time as soon as the clock change occured.
But guess what... Windows doesn't issue a WM_TIMECHANGE message when it changes the time for daylight savings. Now that's consistency...
Monday 25 June 2007
Roadmap chat with David I
How many of you joined in on one of the CodeGear Developer Network Delphi/C++ roadmap chats last week, hosted by David I? I did on Friday afternoon (well, Friday 4pm UK time, which was 8am PDT; I nearly missed it as the UK is currently on British Summer Time which is GMT+1 but that's another story).
It was an hour well spent and had a star-studded cast as I wasn't expecting Nick Hodges & Anders Ohlsson to be there too. The presentation was fine, the Interwise client held up well but the Q&A was the intetesting part.
I (rather cheekily) asked if the recent update to the roadmap where Highlander will now also be able to create generics was as a result of the noise made by the community. Nick answered rather nicely, firstly joking that of course he should say "Yes, we listened to our customers" but admitting that actually they pretty much knew it would cause a fuss and that they'd actually almost made the decision to allow creation of generics before the roadmap was published but didn't want to delay its publication. Fair enough, I'm sure it's no small matter and we're all pleased to see this "living document" evolving.
I also asked, on a different matter, if they could confirm that buying Delphi 2007 and Software Assurance (SA) really does mean I'd get any Studio product released during the SA period. They said yes but note that you need to buy the RAD Studio level of SA, not just the Delphi one if that's what you want.
In hindsight, I wished I'd asked about WinForms in Highlander. Roland Beenhakker on his Delphi Power Unleashed blog pointed towards a post by the excellent Julian Bucknall about WinForms being dropped in Highlander. Huh? Now I'm not in a position to comment hugely on this as I'm not making any moves towards .NET at present, but when I did I had hoped I would stay with Delphi. But if Delphi for .NET doesn't go on to support the standard, i.e. WinForms, then how can this product compete? Can it consume .NET code written in other languages which is, after all, supposed to be one of the principles? I'd be interested to know what drove this decision?
I should balance this out and point out that the community have made it clear that they'd prefer CodeGear to concentrate on improving the products rather than chasing the Next Big Thing, and clearly that was what Delphi 2007 for Win32 was all about. So is this decision to do with that?
Update: Marco Cantu has, as ever, joined in with a well written and well balanced view on WinForms and CodeGear's decision to drop them. I agree wholeheartedly with what he says, after all it seems even Microsoft is walking away from them too.
It was an hour well spent and had a star-studded cast as I wasn't expecting Nick Hodges & Anders Ohlsson to be there too. The presentation was fine, the Interwise client held up well but the Q&A was the intetesting part.
I (rather cheekily) asked if the recent update to the roadmap where Highlander will now also be able to create generics was as a result of the noise made by the community. Nick answered rather nicely, firstly joking that of course he should say "Yes, we listened to our customers" but admitting that actually they pretty much knew it would cause a fuss and that they'd actually almost made the decision to allow creation of generics before the roadmap was published but didn't want to delay its publication. Fair enough, I'm sure it's no small matter and we're all pleased to see this "living document" evolving.
I also asked, on a different matter, if they could confirm that buying Delphi 2007 and Software Assurance (SA) really does mean I'd get any Studio product released during the SA period. They said yes but note that you need to buy the RAD Studio level of SA, not just the Delphi one if that's what you want.
In hindsight, I wished I'd asked about WinForms in Highlander. Roland Beenhakker on his Delphi Power Unleashed blog pointed towards a post by the excellent Julian Bucknall about WinForms being dropped in Highlander. Huh? Now I'm not in a position to comment hugely on this as I'm not making any moves towards .NET at present, but when I did I had hoped I would stay with Delphi. But if Delphi for .NET doesn't go on to support the standard, i.e. WinForms, then how can this product compete? Can it consume .NET code written in other languages which is, after all, supposed to be one of the principles? I'd be interested to know what drove this decision?
I should balance this out and point out that the community have made it clear that they'd prefer CodeGear to concentrate on improving the products rather than chasing the Next Big Thing, and clearly that was what Delphi 2007 for Win32 was all about. So is this decision to do with that?
Update: Marco Cantu has, as ever, joined in with a well written and well balanced view on WinForms and CodeGear's decision to drop them. I agree wholeheartedly with what he says, after all it seems even Microsoft is walking away from them too.
Friday 22 June 2007
Real-world tools #2: Database connectivity
OK, so yesterday I was on pretty sure footing with talking about ReportBuilder. Some of your comments and emails reflected that this is a popular third-party toolset and ranks up there with other report writing tools in Delphi. At least, undoubtely, most of you have at least heard of it. Today, I'm going to discuss a component set at the other end of the scale, although I may be proved wrong.
One of Delphi 1's initial selling point was that it was for the design of database applications, and was of course shipped with the BDE to give us connectivity to most of the big databases around at that time: Access, SQL Server, Oracle and Borland's own Interbase and Paradox. Eventually, like most of you probably, I looked for an alternative. Something that didn't require me to install the BDE for a start. I don't remember when or why this need occurred (can you?) but eventually I sought out a third-party solution. And the choice was plentiful.
At that time, our software was based around Microsoft Access (snigger), and so although the BDE could cut it, we just didn't want our software to be the reason that the BDE was installed on the end user machine. In fact, the prerequisite for any alternative was that there should be no installation of any other proprietary files, period.
This led us to Titan Access by Reggatta Systems. This was ideal for us at that time, as it used the Jet engine (DAO) itself and only required a few files to be installed which, if they had Office, were on the PC anyway.
This was a great alternative to the BDE, and the components were so close to the BDE ones that it took no time to change the product to use it. This was fine until the company and the software grew out of Access and towards MS SQL Server. We knew the size of the companies we were trying to get into would have had SQL Server installed for their other Enterprise-level applications (at least this was the feedback we were getting) so it was natural for us to go down this route.
And although this is about components, not databases, I'm glad we did.
At this point, we had to seek another alternative. Reggatta also provide the same component set for Sybase SQL Anywhere but we spent some time evaluating this database and didn't get on with it for reasons I can no longer remember (this was mid-2001). So we needed a solution that enabled us to use both Access and SQL Server: ODBC.
At that time, the ODBC had a terrible reputation for being slow and clunky, but we seemed to catch it just as it was on the rise and approval for it was improving. Thank God we were right, it still remains a viable alternative and Microsoft continue to update their drivers for it every time they issue a major release of IE or Windows. There was talk some years ago about them starting to drop support for it in favour of the upcoming newboy, ADO. That never happened and the two now co-exist perfectly happily.
There were plenty of ODBC Delphi component sets on the market and again I cannot remember what it was that led me down the route to ODBCExpress. I think there was an article in Delphi Informant about it that probably swayed me, not least because then at least I had a tutorial in getting it up and running. Also, at that time, dbExpress had been launched but the SQL Server driver for it was "unavailable" and the way to use Access with it was simply to use an ODBC driver.
Since then, this component set has actually been one of the most reliable we have ever installed. I think we've only ever needed to upgrade to a new version once, and that was only because we were moving from Delphi 5 to Delphi 6.
Any weaknesses it has actually aren't in the components: they're in the drivers themselves. This is where you potentially have an issue. But the components are excellent, they do the job well and provide many of the options that ODBC supports. For those options that are database specific, it has the ability to tap into those as well so, for example, you can query the SQL Server ODBC driver about the database you are connected to, even though these calls are exclusive to that driver.
The strength of any ODBC component set is in the database drivers you are using. This is partly why we chose SQL Server 6 years ago, because we knew Microsoft would produce high quality drivers for it whereas we couldn't be sure of the quality of other database vendors.
The other beauty is that it has enabled us to toy with adding support for other databases (with a decent ODBC driver) to our software. This sounds good in theory but actually when you consider that none of them really stick to the same ANSI-92 SQL standards, you can end up with different SQL statements in your code depending on which database you're connecting to. Tim Anderson's blog had an article this week about SQLite and how they have had to deal with the same issue, so you wouldn't be alone in this!
The newsgroup support is adequate. It doesn't set the world on fire but Pieter Myburgh seems to single-handedly keep it alive and answer everyones' questions. But I do wonder how it would survive without him and you can tell when he is on holiday because the newsgroups don't get answered. Also, ODBCExpress used to be listed on Korbitec's website but it isn't any longer, even though Pieter's email address is still at Korbitec.
That said, the last release supported Delphi 2006 and it has a C++Builder version as well. There doesn't appear to be any movement for Delphi 2007 but given that it is a non-breaking release and the newsgroups suggest the 2006 version works fine under 2007, there's no need for them to bust out a new version.
This is a minor player in the toolset market and the database connectivity market doesn't seem to be as big as it used to be. Maybe because Borland released the dbExpress components and supported ADO out of the box with Delphi 6. And even more so when CodeGear announced DBX4 with Delphi 2007 for Win32.
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 for two reasons: firstly, I've used the same version of ODBCExpress for nearly 5 years without a problem - and that's without the source code (I know, what was I thinking?!); and secondly, 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.
What do you use? Why do you use it, why did you choose it and are you glad you did?
I'm going to be listening in one of the David I's CodeGear Delphi and C++Builder Roadmap Community Chat & Demos in a bit.
One of Delphi 1's initial selling point was that it was for the design of database applications, and was of course shipped with the BDE to give us connectivity to most of the big databases around at that time: Access, SQL Server, Oracle and Borland's own Interbase and Paradox. Eventually, like most of you probably, I looked for an alternative. Something that didn't require me to install the BDE for a start. I don't remember when or why this need occurred (can you?) but eventually I sought out a third-party solution. And the choice was plentiful.
At that time, our software was based around Microsoft Access (snigger)
This led us to Titan Access by Reggatta Systems. This was ideal for us at that time, as it used the Jet engine (DAO) itself and only required a few files to be installed which, if they had Office, were on the PC anyway.
This was a great alternative to the BDE, and the components were so close to the BDE ones that it took no time to change the product to use it. This was fine until the company and the software grew out of Access and towards MS SQL Server. We knew the size of the companies we were trying to get into would have had SQL Server installed for their other Enterprise-level applications (at least this was the feedback we were getting) so it was natural for us to go down this route.
And although this is about components, not databases, I'm glad we did.
At this point, we had to seek another alternative. Reggatta also provide the same component set for Sybase SQL Anywhere but we spent some time evaluating this database and didn't get on with it for reasons I can no longer remember (this was mid-2001). So we needed a solution that enabled us to use both Access and SQL Server: ODBC.
At that time, the ODBC had a terrible reputation for being slow and clunky, but we seemed to catch it just as it was on the rise and approval for it was improving. Thank God we were right, it still remains a viable alternative and Microsoft continue to update their drivers for it every time they issue a major release of IE or Windows. There was talk some years ago about them starting to drop support for it in favour of the upcoming newboy, ADO. That never happened and the two now co-exist perfectly happily.
There were plenty of ODBC Delphi component sets on the market and again I cannot remember what it was that led me down the route to ODBCExpress. I think there was an article in Delphi Informant about it that probably swayed me, not least because then at least I had a tutorial in getting it up and running. Also, at that time, dbExpress had been launched but the SQL Server driver for it was "unavailable" and the way to use Access with it was simply to use an ODBC driver.
Since then, this component set has actually been one of the most reliable we have ever installed. I think we've only ever needed to upgrade to a new version once, and that was only because we were moving from Delphi 5 to Delphi 6.
Any weaknesses it has actually aren't in the components: they're in the drivers themselves. This is where you potentially have an issue. But the components are excellent, they do the job well and provide many of the options that ODBC supports. For those options that are database specific, it has the ability to tap into those as well so, for example, you can query the SQL Server ODBC driver about the database you are connected to, even though these calls are exclusive to that driver.
The strength of any ODBC component set is in the database drivers you are using. This is partly why we chose SQL Server 6 years ago, because we knew Microsoft would produce high quality drivers for it whereas we couldn't be sure of the quality of other database vendors.
The other beauty is that it has enabled us to toy with adding support for other databases (with a decent ODBC driver) to our software. This sounds good in theory but actually when you consider that none of them really stick to the same ANSI-92 SQL standards, you can end up with different SQL statements in your code depending on which database you're connecting to. Tim Anderson's blog had an article this week about SQLite and how they have had to deal with the same issue, so you wouldn't be alone in this!
The newsgroup support is adequate. It doesn't set the world on fire but Pieter Myburgh seems to single-handedly keep it alive and answer everyones' questions. But I do wonder how it would survive without him and you can tell when he is on holiday because the newsgroups don't get answered. Also, ODBCExpress used to be listed on Korbitec's website but it isn't any longer, even though Pieter's email address is still at Korbitec.
That said, the last release supported Delphi 2006 and it has a C++Builder version as well. There doesn't appear to be any movement for Delphi 2007 but given that it is a non-breaking release and the newsgroups suggest the 2006 version works fine under 2007, there's no need for them to bust out a new version.
This is a minor player in the toolset market and the database connectivity market doesn't seem to be as big as it used to be. Maybe because Borland released the dbExpress components and supported ADO out of the box with Delphi 6. And even more so when CodeGear announced DBX4 with Delphi 2007 for Win32.
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 for two reasons: firstly, I've used the same version of ODBCExpress for nearly 5 years without a problem - and that's without the source code (I know, what was I thinking?!); and secondly, 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.
What do you use? Why do you use it, why did you choose it and are you glad you did?
I'm going to be listening in one of the David I's CodeGear Delphi and C++Builder Roadmap Community Chat & Demos in a bit.
Thursday 21 June 2007
Real-world tools #1: ReportBuilder
There are some third-party components I use that I'm still not sure about, but that are so embedded in my work now that the thought of changing them isn't all that appealing. ReportBuilder (RB), by Digital Metaphors, isn't one of those. This, it turns out, is one of the best decisions I ever made. My experience below is based on version 10 Enterprise.
I think I first read about it in the Delphi Informant magazine about eight or nine years ago when an article was written that was a semi-tutorial and review at the same time. One of the nice things for me is that this is all that Digital Metaphors do: a report writer for Delphi. The product has now been around for a long time and during the time that Delphi Informant was running, ReportBuilder won Best Reporting Tool and Best Product of the Year for several years running.
There are a few really good reporting solutions out there, all of which are such a pleasure to use after using QuickReports! I guess a lot of Delphi developers use Rave Reports since it started being bundled with Delphi, but by the time this had happened, I was already ensconced in ReportBuilder.
For a start, it is written fantastically well. If you ever needed convincing that object-oriented code was the way forward but and never looked at the Delphi VCL, you should see ReportBuilder's code. It's simply the most extensible, accessible and flexible code I have ever come across. There isn't a part of the software that you can't change, get to, manhandle or simply read. As each version progresses and they add new features, they actually go back and make the existing features easier to use as well by exposing more properties.
For me, the best example of this is the report query itself (if you're not attaching to a dataset which, of course, you can). Once you have built up your query (using either the standard Query Wizard or Designer, or your own custom Query Wizard or Designer), you can then access the query as an object. And each part of that query is an object too, so you have the Criteria object and the Join object, etc. You can access this at run-time so you can amend the query to suit your needs just before the report runs, or at least see the query that has been generated for you. Simply use the object properties and methods to change the query and the SQL text itself is updated. This is simply genius and so much easier than having to manually trawl through the query text in order to add a table and its join at a later stage.
As I mentioned, any of the wizards or dialogs can be descended from to make your own class, which you then register with RB and use those instead.
And this mechanism is what allows it to communicate with any database class out there. Of course you're given default support for the BDE, text files and "Just-In-Time" data sources, but because they all descend from a base class, you can use any others on the market. I myself wrote ones for Titan Access and Titan SQLAnywhere by Reggatta Systems when we used those components (more on that another day), and I've had some input on the class for ODBCExpress. Once compiled, RB can connect to your third-party database interface and you'll never think about it again.
Similarly, the new email feature in version 10 supports MAPI and Indy 9 and 10 from different classes, but if you use another SMTP facility then a new class can be derived to support it.
Like Delphi, RB comes in different flavours for different prices. Standard is the entry level system which only allows you to write reports; the next step up, Professional, allows you to include the designer within your software to offer a report-writing solution. Enterprise adds RAP capability which I'll come to below, and Server Edition adds web server support for displaying your reports on the web.
RAP was formally introduced I think in about version 6, although it had been available in beta stage for some versions prior to that. Report Application Pascal is basically a mini-Delphi within the report writer, whereby you can add code to events of the report or any of its components - just like a TForm and the components you drop on it. With each new version, the RAP language expands allowing more and more control over the look and data output of your report. This is so powerful that I can't imagine how I ever wrote a report without it. If you use Crystal Reports, it's similar to the formula language used within it. And like Crystal, you can extend it if a method or class you want isn't in it.
This isn't meant to be a sales pitch for Digital Metaphors so I won't go on to list all of its features, but I should commend them for their excellent technical support via the newsgroups. There are groups for the different sections of report writing and often they will contact you directly if you have raised an issue so you can sort it out between you before the newsgroup is given the solution.
No matter what happens, this is one toolset that actually drives which version of Delphi we use, and as ever they are supporting the latest version of Delphi almost as soon as anyone.
Personally, I believe ReportBuilder is about as good as third-party components get. We recently made significant database changes to our main software in order that we could move forward with bigger and better features. This wasn't an easy change, it took almost 6 months to get the software working as it was before the changes, and of course it was going to affect every user-defined report written using our software, over which we have no control (that's the point after all, isn't it?). So how did we get all these user reports to play nicely with the massive database restructure? We wrote a conversion utility that changed the SQL of the reports, using RB's SQLBuilder object. How easy did that make it? Well let's just say that I'd still be manually changing them now if that wasn't available. As it was, we never received a single user report by email to convert; we could see the reports as code, change the code as necessary, and save it back.
That alone was worth the price.
I think I first read about it in the Delphi Informant magazine about eight or nine years ago when an article was written that was a semi-tutorial and review at the same time. One of the nice things for me is that this is all that Digital Metaphors do: a report writer for Delphi. The product has now been around for a long time and during the time that Delphi Informant was running, ReportBuilder won Best Reporting Tool and Best Product of the Year for several years running.
There are a few really good reporting solutions out there, all of which are such a pleasure to use after using QuickReports! I guess a lot of Delphi developers use Rave Reports since it started being bundled with Delphi, but by the time this had happened, I was already ensconced in ReportBuilder.
For a start, it is written fantastically well. If you ever needed convincing that object-oriented code was the way forward but and never looked at the Delphi VCL, you should see ReportBuilder's code. It's simply the most extensible, accessible and flexible code I have ever come across. There isn't a part of the software that you can't change, get to, manhandle or simply read. As each version progresses and they add new features, they actually go back and make the existing features easier to use as well by exposing more properties.
For me, the best example of this is the report query itself (if you're not attaching to a dataset which, of course, you can). Once you have built up your query (using either the standard Query Wizard or Designer, or your own custom Query Wizard or Designer), you can then access the query as an object. And each part of that query is an object too, so you have the Criteria object and the Join object, etc. You can access this at run-time so you can amend the query to suit your needs just before the report runs, or at least see the query that has been generated for you. Simply use the object properties and methods to change the query and the SQL text itself is updated. This is simply genius and so much easier than having to manually trawl through the query text in order to add a table and its join at a later stage.
As I mentioned, any of the wizards or dialogs can be descended from to make your own class, which you then register with RB and use those instead.
And this mechanism is what allows it to communicate with any database class out there. Of course you're given default support for the BDE, text files and "Just-In-Time" data sources, but because they all descend from a base class, you can use any others on the market. I myself wrote ones for Titan Access and Titan SQLAnywhere by Reggatta Systems when we used those components (more on that another day), and I've had some input on the class for ODBCExpress. Once compiled, RB can connect to your third-party database interface and you'll never think about it again.
Similarly, the new email feature in version 10 supports MAPI and Indy 9 and 10 from different classes, but if you use another SMTP facility then a new class can be derived to support it.
Like Delphi, RB comes in different flavours for different prices. Standard is the entry level system which only allows you to write reports; the next step up, Professional, allows you to include the designer within your software to offer a report-writing solution. Enterprise adds RAP capability which I'll come to below, and Server Edition adds web server support for displaying your reports on the web.
RAP was formally introduced I think in about version 6, although it had been available in beta stage for some versions prior to that. Report Application Pascal is basically a mini-Delphi within the report writer, whereby you can add code to events of the report or any of its components - just like a TForm and the components you drop on it. With each new version, the RAP language expands allowing more and more control over the look and data output of your report. This is so powerful that I can't imagine how I ever wrote a report without it. If you use Crystal Reports, it's similar to the formula language used within it. And like Crystal, you can extend it if a method or class you want isn't in it.
This isn't meant to be a sales pitch for Digital Metaphors so I won't go on to list all of its features, but I should commend them for their excellent technical support via the newsgroups. There are groups for the different sections of report writing and often they will contact you directly if you have raised an issue so you can sort it out between you before the newsgroup is given the solution.
No matter what happens, this is one toolset that actually drives which version of Delphi we use, and as ever they are supporting the latest version of Delphi almost as soon as anyone.
Personally, I believe ReportBuilder is about as good as third-party components get. We recently made significant database changes to our main software in order that we could move forward with bigger and better features. This wasn't an easy change, it took almost 6 months to get the software working as it was before the changes, and of course it was going to affect every user-defined report written using our software, over which we have no control (that's the point after all, isn't it?). So how did we get all these user reports to play nicely with the massive database restructure? We wrote a conversion utility that changed the SQL of the reports, using RB's SQLBuilder object. How easy did that make it? Well let's just say that I'd still be manually changing them now if that wasn't available. As it was, we never received a single user report by email to convert; we could see the reports as code, change the code as necessary, and save it back.
That alone was worth the price.
Wednesday 20 June 2007
Tools of the real world
I should explain what it is I do with Delphi every day, which will maybe give a background as to why I've become what I consider a conservative developer. Conservative, that is, in terms of what software we use. The company I have worked for for the past 9 years develops three main products (payroll, HR and Time & Attendance, combined as a suite), written for Windows using Delphi.
Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.
Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.
I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.
It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.
It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:
Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.
Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.
I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.
It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.
It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:
- ReportBuilder 10 (Digital Metaphors)
- ODBCExpress (Korbitec)
- TMS Component Pack (TMS Software)
- IP*Works! SSL (/n Software)
- Indy 9 (Nevrona)
- JEDI VCL
- Crystal Reports VCL
Tuesday 19 June 2007
Introduction
dis·ci·ple (dĭ-sī'pl)
n.
One who embraces and assists in spreading the teachings of another. An active adherent, as of a movement or philosophy.
OK, so does the Delphi Community need another blogger? Probably not, but the reason whyBorland Inprise Borland CodeGear has survived is because of the strength of that community, like none other. I have used that community, I have given back to that community. If we all do the same, then it remains the most valuable resource we all have.
n.
One who embraces and assists in spreading the teachings of another. An active adherent, as of a movement or philosophy.
OK, so does the Delphi Community need another blogger? Probably not, but the reason why
Why The Delphi Disciple? Well amongst our very (very) learned friends are:
The Oracle at Delphi (Allen Bauer)
The Delphi Apostle (Matlus)
The Delphi Evangelist (David I, happy 22nd anniversary BTW) *
So I thought I'd continue the theme, and I am very much a disciple. I work with Delphi every day. I have done since Delphi 1. This isn't necessarily going to teach you things because my peers do a far better job than I ever could. But this will be about how an ordinary guy uses it, struggles with it, loves it and gets the most out of it every day. Perhaps this will be enlightening to those who carry it forward. Perhaps it will be frustrating to you because I'm, by my own admission, a very conservative developer. Maybe some of you will smile as you share my experiences or others may have pearls of wisdom that you've been keeping to yourselves all this time.
My career is now forged around this tool, for better or worse. I've defended it against those who didn't like it because it wasn't Microsoft. I've written articles for the (now sadly defunct) Delphi Informant and Delphi Magazine. I'm by no means a player but I'm part of the Delphi community like it is a part of me and my job.
I'll get going again very soon, I've all sorts in my head to say but in no particular order so let me sort that out so you can read something clear that might make you come back again one day. Unlike my code, very probably.
*(not to mention the Delphi Junkie, Addict and Geek).
Subscribe to:
Posts (Atom)