I've just watched Nick Hodges go through some of the VCL enhancements for Delphi 2009, and two things struck me.
Firstly, I can't understand why the PasswordChar feature on TEdit was being demonstrated; I was running Delphi 6 side-by-side with the video, and was changing this property with the same results. So why is this being advertised as a VCL enhancement when, if I recall correctly, it's been there since Delphi 1.
The other thing is how many of these new controls are similar to the Raize Controls, especially the TButton with images from an imagelist (TRzBitBtn), the TButtonEdit with 2 buttons in the edit control (TRzButtonEdit) and the group bar (TRzGroupBar).
That said, it's nice to have these as standard components, and if I do move to Delphi 2009 then I'd have to think twice about renewing my Raize Components.
Tuesday, 5 August 2008
Tuesday, 3 June 2008
Code: Speed vs Aesthetics
In our drive to produce the fastest, most optimised code out there, sometimes we can leave ourselves with a sprawl of code that no one else is going to be able to follow - or quite possibly you may not be able to follow a few months down the line, even though you wrote it!
I'm not talking about real down-to-the-core assembler or machine code here, just general high-level code that you might look at and think "I could rewrite that so it was a little bit faster", but ultimately leave it much less readable and maintainable for the future.
Take, for example, a reasonably new feature that Digital Metaphors added to its ReportBuilder product a while back: SQLBuilder. As I mentioned back in June last year:
This has always been available using the QueryDataView object, with which you can add and remove tables, fields, joins, etc, in Delphi code without actually touching the underlying query. No need to know which flavour of SQL you're using, or having to find the ORDER BY line to insert a new WHERE criteria above it. Anyway, I'm repeating myself. The point is, you can do this using this object and it's simple but takes a little effort to get to the objects:
function TmyJoinBuilder.GetQueryDataView(aReport: TppReport; var aDataView: TdaQueryDataView): Boolean;
var
lDataModule: TdaDataModule;
begin
aDataView := nil;
{get the datamodule}
lDataModule := daGetDataModule(aReport);
{get the query dataview}
if (lDataModule <> nil) then
if (lDataModule.DataViewCount > 0) then
aDataView := TdaQueryDataView(lDataModule.DataViews[0]);
Result := (aDataView <> nil);
end;
This just to get the QueryDataView object. When SQLBuilder was added, this became a little easier:
and the code to add a new table and join to the query went from this:
procedure TmyJoinBuilder.Add(aReport: TppReport; const aTableName1, aTableName2, aFieldName1, aFieldName2: String; aJoinType: TdaJoinOperatorType);
var
i: Integer;
lQueryDataView: TdaQueryDataView;
lSQL: TdaSQL;
lMainTable: TdaTable;
lNewTable: TdaTable;
begin
{get the query dataview for this report}
GetQueryDataView(aReport, lQueryDataView);
{get the TdaSQL object}
lSQL := lQueryDataView.SQL;
{get the main table}
lMainTable := GetTable(lSQL, aTableName1);
if (lMainTable <> nil) then
begin
lNewTable := GetTable(lSQL, aTableName2);
if (lNewTable = nil) then
begin
lNewTable := lSQL.AddTable(aTableName2);
end;
{add the table join}
if not (DoesJoinExist(lMainTable, lNewTable, aFieldName1, aFieldName2, aJoinType)) then
begin
lNewTable.AddTableJoin(lMainTable, aFieldName1, aFieldName2, aJoinType);
{call out of sync to ensure the sql result is refreshed}
lQueryDataView.OutOfSync;
end;
end;
end;
to this:
lSQLBuilder.SelectTables.AddJoin(lNewTable, lMainTable, 'Field_name', '=', 'Join_to_field_name');
Now I know that what ReportBuilder is doing is actually wrapping all of the long code into one method call for me, and possibly doing a little bit more than I am doing as well in order to be robust. But the readability and maintainability of my code has now increased beyond what speed impact there might be. (For the record, I haven't noticed any, but we're not doing lightning fast mathematical wizardry here in which every millisecond counts).
Sometimes you even know that doing it the short way means some lower-level code is called multiple times. But isn't the end result more pleasing than the speed offset?
I'm not talking about real down-to-the-core assembler or machine code here, just general high-level code that you might look at and think "I could rewrite that so it was a little bit faster", but ultimately leave it much less readable and maintainable for the future.
Take, for example, a reasonably new feature that Digital Metaphors added to its ReportBuilder product a while back: SQLBuilder. As I mentioned back in June last year:
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
This has always been available using the QueryDataView object, with which you can add and remove tables, fields, joins, etc, in Delphi code without actually touching the underlying query. No need to know which flavour of SQL you're using, or having to find the ORDER BY line to insert a new WHERE criteria above it. Anyway, I'm repeating myself. The point is, you can do this using this object and it's simple but takes a little effort to get to the objects:
function TmyJoinBuilder.GetQueryDataView(aReport: TppReport; var aDataView: TdaQueryDataView): Boolean;
var
lDataModule: TdaDataModule;
begin
aDataView := nil;
{get the datamodule}
lDataModule := daGetDataModule(aReport);
{get the query dataview}
if (lDataModule <> nil) then
if (lDataModule.DataViewCount > 0) then
aDataView := TdaQueryDataView(lDataModule.DataViews[0]);
Result := (aDataView <> nil);
end;
This just to get the QueryDataView object. When SQLBuilder was added, this became a little easier:
lSQLBuilder := TdaSQLBuilder.Create(aReport);
and the code to add a new table and join to the query went from this:
procedure TmyJoinBuilder.Add(aReport: TppReport; const aTableName1, aTableName2, aFieldName1, aFieldName2: String; aJoinType: TdaJoinOperatorType);
var
i: Integer;
lQueryDataView: TdaQueryDataView;
lSQL: TdaSQL;
lMainTable: TdaTable;
lNewTable: TdaTable;
begin
{get the query dataview for this report}
GetQueryDataView(aReport, lQueryDataView);
{get the TdaSQL object}
lSQL := lQueryDataView.SQL;
{get the main table}
lMainTable := GetTable(lSQL, aTableName1);
if (lMainTable <> nil) then
begin
lNewTable := GetTable(lSQL, aTableName2);
if (lNewTable = nil) then
begin
lNewTable := lSQL.AddTable(aTableName2);
end;
{add the table join}
if not (DoesJoinExist(lMainTable, lNewTable, aFieldName1, aFieldName2, aJoinType)) then
begin
lNewTable.AddTableJoin(lMainTable, aFieldName1, aFieldName2, aJoinType);
{call out of sync to ensure the sql result is refreshed}
lQueryDataView.OutOfSync;
end;
end;
end;
to this:
lSQLBuilder.SelectTables.AddJoin(lNewTable, lMainTable, 'Field_name', '=', 'Join_to_field_name');
Now I know that what ReportBuilder is doing is actually wrapping all of the long code into one method call for me, and possibly doing a little bit more than I am doing as well in order to be robust. But the readability and maintainability of my code has now increased beyond what speed impact there might be. (For the record, I haven't noticed any, but we're not doing lightning fast mathematical wizardry here in which every millisecond counts).
Sometimes you even know that doing it the short way means some lower-level code is called multiple times. But isn't the end result more pleasing than the speed offset?
Thursday, 24 January 2008
Real-world tools #6: Raize Components
Despite the claims that I don't like to have reams of different component packs installed in Delphi, there is often a case that a particular component set just has that killer component that demands its use. I've been aware of Raize Components for years but never made the leap of using them because I'd committed myself to TMS and JEDI, and that was enough for me.
Late last year, I attended a UK Developer's Group workshop with Ray Konopka, on UI design. It was an excellent couple of days and Ray, as I've seen him do in conference presentations, managed to not so subtley slip in references in Raize Components and CodeSite. And now I can see why... I was about the only one in the room that wasn't using Raize Components, and now I am converted.
So why take the decision to add yet another component set? Well, it was a trade-off for me. If Raize Components could do everything that I was using from an existing component pack, then I'd go with it. So I trialled it and two things stood out for me.
1. The TRzBitBtn supports XP/Vista themes where appropriate and uses the ImageList for its image property, not the Glyph property. This meant that I could use it to replace the TJvImgBtn from the JVCL, which frankly was the only component I was using from it regularly.
In fact, almost every component supports XP/Vista themes, and almost everything has the ability to use system colours, Office colours or custom gradients. The results are stunning. TMS offer this with their AdvOffice components too but I've had issues with it on Delphi 6 and Bruno told me in an email that they were looking to drop support for Delphi 6, and so they weren't going to be resolved for me. (But rest assured, the Styler mechanism in TMS is absolutely brilliant and a doddle to set up).
2. Almost every visual Raize control has a Transparent property. This is exactly what I have been looking for, for some time now, as we move into form design with gradient colours. Having a transparent panel, page control, group box, radio group box, etc, means that I can use gradient colours on a form and still have groups & panels.
Once I'd seen those two I was convinced, but it got better. The RzToolBar & RzPageControl replacements are so far superior to the standard VCL controls (and solve all the bugs I was having with those controls, which are just wrappers of the Windows Common Controls); the design-time editors that are installed as part of the Raize Component pack are so helpful that when you use an IDE that doesn't have them, you're left frustrated; and the edit boxes with the buttons actually as part of them mean that I no longer have to have a separate edit box and BitBtn next to it.
I could go on and there are similar components out there in other component packs, but what makes the difference is the standard way they look and behave, and the superb documentation that is lacking from almost all other third-party packs out there.
So JEDI has almost gone for me. With all due respect to the JEDI developers, who put in so much time and good, hard work, but there's just too many components for me to handle, and they're all a little bit different because of the nature of the open-source community. I say almost gone, because there are a few components that are actually irreplaceable, like the TJvWizard. Once you've used it, you'll never go back to a form with a PageControl on it.
What I also like about the Raize Components is that they are simple to upgrade. When a new release comes out, I don't even have to uninstall packages or worry about losing settings; the installer just works, updates my files and allows me to fire up Delphi and move on. Which takes the headache out of getting the latest version.
Ray takes what he talks about in his UI Design talk and implements it into a quality product, that adheres to his design principles and offers you controls that behave as you'd expect them to. And as Ray himself says, that's rule #1 of good UI design: it behaves as the user expects it to.
Late last year, I attended a UK Developer's Group workshop with Ray Konopka, on UI design. It was an excellent couple of days and Ray, as I've seen him do in conference presentations, managed to not so subtley slip in references in Raize Components and CodeSite. And now I can see why... I was about the only one in the room that wasn't using Raize Components, and now I am converted.
So why take the decision to add yet another component set? Well, it was a trade-off for me. If Raize Components could do everything that I was using from an existing component pack, then I'd go with it. So I trialled it and two things stood out for me.
1. The TRzBitBtn supports XP/Vista themes where appropriate and uses the ImageList for its image property, not the Glyph property. This meant that I could use it to replace the TJvImgBtn from the JVCL, which frankly was the only component I was using from it regularly.
In fact, almost every component supports XP/Vista themes, and almost everything has the ability to use system colours, Office colours or custom gradients. The results are stunning. TMS offer this with their AdvOffice components too but I've had issues with it on Delphi 6 and Bruno told me in an email that they were looking to drop support for Delphi 6, and so they weren't going to be resolved for me. (But rest assured, the Styler mechanism in TMS is absolutely brilliant and a doddle to set up).
2. Almost every visual Raize control has a Transparent property. This is exactly what I have been looking for, for some time now, as we move into form design with gradient colours. Having a transparent panel, page control, group box, radio group box, etc, means that I can use gradient colours on a form and still have groups & panels.
Once I'd seen those two I was convinced, but it got better. The RzToolBar & RzPageControl replacements are so far superior to the standard VCL controls (and solve all the bugs I was having with those controls, which are just wrappers of the Windows Common Controls); the design-time editors that are installed as part of the Raize Component pack are so helpful that when you use an IDE that doesn't have them, you're left frustrated; and the edit boxes with the buttons actually as part of them mean that I no longer have to have a separate edit box and BitBtn next to it.
I could go on and there are similar components out there in other component packs, but what makes the difference is the standard way they look and behave, and the superb documentation that is lacking from almost all other third-party packs out there.
So JEDI has almost gone for me. With all due respect to the JEDI developers, who put in so much time and good, hard work, but there's just too many components for me to handle, and they're all a little bit different because of the nature of the open-source community. I say almost gone, because there are a few components that are actually irreplaceable, like the TJvWizard. Once you've used it, you'll never go back to a form with a PageControl on it.
What I also like about the Raize Components is that they are simple to upgrade. When a new release comes out, I don't even have to uninstall packages or worry about losing settings; the installer just works, updates my files and allows me to fire up Delphi and move on. Which takes the headache out of getting the latest version.
Ray takes what he talks about in his UI Design talk and implements it into a quality product, that adheres to his design principles and offers you controls that behave as you'd expect them to. And as Ray himself says, that's rule #1 of good UI design: it behaves as the user expects it to.
Thursday, 20 September 2007
Real-world tools #5: IP*Works! SSL
It's been a while and for that I apologise, although perhaps many of you are grateful that it's taken 2 months for me to post. Usual stuff, I know you're all up against the same things. Deadlines, massive development schedules, testing, meetings... you know, real-world stuff.
I wanted to get back into this by explaining briefly why I chose IP*Works! from /n software. It came about because part of our payroll product needed to consume a web service written by (or for) the UK's revenue department, HMRC.
Version 1 of this web service was more basic than its successor, and as a result the standard SOAP Web Services tools that came with Delphi 6 were sufficient to do the job. Good old Delphi does the trick again, out of the box.
A year or so after version 1, the whole HMRC service was redesigned and so version 2 of the web service was born. Whilst it remained on the SOAP platform (due to a unanimous decision from the software developers that had to ultimately consume it), they introduced an element into version 2 that Delphi 6 did not handle: SOAP headers.
At this point, I had 3 options. Option 1 was to move to Delphi 7 in which support for SOAP headers was introduced as standard. Option 2 was to try the Indy Soap which also claimed to support SOAP headers. Option 3 was to buy a third-party product.
My preferred option was number 2, not least because it enabled me to stay with the version of Delphi I was on and we were already using the awesome Indy components for other HTTP, FTP and SMTP work. However, I failed 100% to even get this code to compile despite the help of the indy-soap-public Yahoo group. I decided this was going to be too much of a battle to even get started and so investigated option 1, upgrading Delphi.
This was a tricky decision, because although Delphi 7 would have given me what I needed, Delphi 2005 had been released by then. I felt that it would be ridiculous to spend all the time and effort moving from D6 to D7, along with upgrading all the third-party tools, etc, when it wasn't even the latest release. But I couldn't justify at that time a move to D2005 because it was taking a knock amongst its users, the cost was much higher and, crucially, I couldn't get a definitive answer on whether the SOAP stuff from D6/7 would work in D2005.
After coming to the disappointing decision that I wasn't going to upgrade from Delphi 6 at this time, and with development time running out, option 3 remained: a third-party tool. This was my least preferred for reasons I have explained in earlier posts: I don't like tabs and tabs of third-party components when I could have used a standard one. However, sometimes the guys who write these third-party tools are experts and sell stacks of their product for good reason, and IP*Works! fell under this category.
I had to buy the more expensive SSL version because the HMRC web service was run on a secure server but this wasn't a real issue. It essentially meant that I got all of the same components as with the non-SSL version but with the option to use secure communications or not.
IP*Works! SSL V6 Delphi Edition (still the current release) is a terrific product and I got the secure web service running within days, including all the extra SOAP header bits that I'd not been able to do with D6. If I hadn't have had such success with the other Indy components (HTTP, FTP, SMTP, etc) then I would have used the IP*Works! ones. It turns out that it was an expensive suite for just using 1 component for one utility, but it is a killer utility that pushed us ahead of the competition for a while.
When (not if) I finally do makr the jump to D2007 or RAD Studio 2007, it's likely I'll try and redo this utility to use Delphi's in-built SOAP objects because that it always my goal, to get back to as few third-party ties as possible. But for now the IP*Works! components are solid, robust, well designed and well documented and this is a purchase I didn't regret.
Although, an asterisk and an exclamation mark in a product's name drives me crazy!
I wanted to get back into this by explaining briefly why I chose IP*Works! from /n software. It came about because part of our payroll product needed to consume a web service written by (or for) the UK's revenue department, HMRC.
Version 1 of this web service was more basic than its successor, and as a result the standard SOAP Web Services tools that came with Delphi 6 were sufficient to do the job. Good old Delphi does the trick again, out of the box.
A year or so after version 1, the whole HMRC service was redesigned and so version 2 of the web service was born. Whilst it remained on the SOAP platform (due to a unanimous decision from the software developers that had to ultimately consume it), they introduced an element into version 2 that Delphi 6 did not handle: SOAP headers.
At this point, I had 3 options. Option 1 was to move to Delphi 7 in which support for SOAP headers was introduced as standard. Option 2 was to try the Indy Soap which also claimed to support SOAP headers. Option 3 was to buy a third-party product.
My preferred option was number 2, not least because it enabled me to stay with the version of Delphi I was on and we were already using the awesome Indy components for other HTTP, FTP and SMTP work. However, I failed 100% to even get this code to compile despite the help of the indy-soap-public Yahoo group. I decided this was going to be too much of a battle to even get started and so investigated option 1, upgrading Delphi.
This was a tricky decision, because although Delphi 7 would have given me what I needed, Delphi 2005 had been released by then. I felt that it would be ridiculous to spend all the time and effort moving from D6 to D7, along with upgrading all the third-party tools, etc, when it wasn't even the latest release. But I couldn't justify at that time a move to D2005 because it was taking a knock amongst its users, the cost was much higher and, crucially, I couldn't get a definitive answer on whether the SOAP stuff from D6/7 would work in D2005.
After coming to the disappointing decision that I wasn't going to upgrade from Delphi 6 at this time, and with development time running out, option 3 remained: a third-party tool. This was my least preferred for reasons I have explained in earlier posts: I don't like tabs and tabs of third-party components when I could have used a standard one. However, sometimes the guys who write these third-party tools are experts and sell stacks of their product for good reason, and IP*Works! fell under this category.
I had to buy the more expensive SSL version because the HMRC web service was run on a secure server but this wasn't a real issue. It essentially meant that I got all of the same components as with the non-SSL version but with the option to use secure communications or not.
IP*Works! SSL V6 Delphi Edition (still the current release) is a terrific product and I got the secure web service running within days, including all the extra SOAP header bits that I'd not been able to do with D6. If I hadn't have had such success with the other Indy components (HTTP, FTP, SMTP, etc) then I would have used the IP*Works! ones. It turns out that it was an expensive suite for just using 1 component for one utility, but it is a killer utility that pushed us ahead of the competition for a while.
When (not if) I finally do makr the jump to D2007 or RAD Studio 2007, it's likely I'll try and redo this utility to use Delphi's in-built SOAP objects because that it always my goal, to get back to as few third-party ties as possible. But for now the IP*Works! components are solid, robust, well designed and well documented and this is a purchase I didn't regret.
Although, an asterisk and an exclamation mark in a product's name drives me crazy!
Friday, 27 July 2007
"Do you have a .net version?"
A reasonably common question we get asked these days in tender documents or over the phone is "is your product written in .net?" or similarly "do you have a .net version of your software?". At this point I bite my tongue, take a breath and try to find out exactly why they've asked such a ridiculous question.
Do they understand what they're asking for? Usually not. A .net "version"? As if we have a normal version AND a special .net version?
At what point did .net become a selling point for software? At what point did .net leave the workshops and magazines and conferences and become something that customers actually believed was a feature? At what point did software resellers start putting on their website "written using .net, Microsoft's latest development platform"?
.net isn't a new platform, it's a "framework" for developers. The end user wouldn't be able to tell if software was written in .net or Win32 because there is no difference to the end-user. There's nothing new in it, nothing fancy or magical, it's just a well-designed foundation for developers to work with. The same one that we as Delphi developers have been using for years. Microsoft brought together years of different technologies and brought them under one roof. Designed by the very man who designed Delphi's OO framework. Nothing new: just the old stuff, revamped and rebadged (oh yeah, with garbage collection added). It's for us, not them.
Another misconception from users/customers/managers is that it's something to do with the internet. I can see why, because the name .net is simply one of the most misleading names in software history. The "net" in .net is a misnomer. It isn't about putting your software into a browser, it's just a rewrite of the Windows development framework. ASP.Net allows you to develop websites, but so did ASP.
A post last year on the Delphi Developer's Group newsgroups asked "Has this whole .net thing been a marketing strategy by MS to boost sales of Visual Studio? Did MS decide Borland, Eclipse and others were encroaching rather too much on the developer tools market and in a brilliant coup de grace has shattered the competition?".
Someone replied, "The thing that annoys me is that .NET is now seen as the latest must-have".
I replied saying how customers are asking if we have a ".net" version and this was well-received as generally the sort of thing customers are asking about.
I'm encouraged, by looking at competitor websites, that almost none of them are developing using .net (or at least their system requirements don't state the .net framework). The more we fight it, the longer they'll have to leave Win32 alone. After all, MS aren't planning to bring the majority of their flagship products across either.
Do they understand what they're asking for? Usually not. A .net "version"? As if we have a normal version AND a special .net version?
At what point did .net become a selling point for software? At what point did .net leave the workshops and magazines and conferences and become something that customers actually believed was a feature? At what point did software resellers start putting on their website "written using .net, Microsoft's latest development platform"?
.net isn't a new platform, it's a "framework" for developers. The end user wouldn't be able to tell if software was written in .net or Win32 because there is no difference to the end-user. There's nothing new in it, nothing fancy or magical, it's just a well-designed foundation for developers to work with. The same one that we as Delphi developers have been using for years. Microsoft brought together years of different technologies and brought them under one roof. Designed by the very man who designed Delphi's OO framework. Nothing new: just the old stuff, revamped and rebadged (oh yeah, with garbage collection added). It's for us, not them.
Another misconception from users/customers/managers is that it's something to do with the internet. I can see why, because the name .net is simply one of the most misleading names in software history. The "net" in .net is a misnomer. It isn't about putting your software into a browser, it's just a rewrite of the Windows development framework. ASP.Net allows you to develop websites, but so did ASP.
A post last year on the Delphi Developer's Group newsgroups asked "Has this whole .net thing been a marketing strategy by MS to boost sales of Visual Studio? Did MS decide Borland, Eclipse and others were encroaching rather too much on the developer tools market and in a brilliant coup de grace has shattered the competition?".
Someone replied, "The thing that annoys me is that .NET is now seen as the latest must-have".
I replied saying how customers are asking if we have a ".net" version and this was well-received as generally the sort of thing customers are asking about.
I'm encouraged, by looking at competitor websites, that almost none of them are developing using .net (or at least their system requirements don't state the .net framework). The more we fight it, the longer they'll have to leave Win32 alone. After all, MS aren't planning to bring the majority of their flagship products across either.
Thursday, 12 July 2007
Business Case for upgrading Delphi
On July 6th, Nick Hodges blogged about a new wiki page he has created entitled the Business Case for Delphi. This is a great idea (admittedly not his own) and for a moment I thought he had stolen my thunder on a topic I've been meaning to write about myself. However, Nick's topic is about why Delphi should be taken on in the first place. Why move? The minimum deployment platform is Windows 2000 and so any Windows 98/Me users could not use the software (according to CodeGear’s site, this hasn’t been confirmed). Note: after I write this, someone added a comment on the Developer's Group newsgroup that they have successfully deployed Delphi 2007 software on Windows 98 and Me with no special code. It could take up to a month to get everything fully migrated across to the new version. This includes all the standard software as well as utilities and plug-ins.
This is not that story.
About 6 weeks ago I wrote an internal document called "The cost & business case for upgrading Delphi". As I have stated before, we're using Delphi 6 here because it is stable, fast and I didn't need any of that .NET junk on my PC. Delphi 7 wasn't considered to be that great a leap from Delphi 6 and so here we stayed. Moreover, it's not just an upgrade of Delphi but also a reinstall of all the third-party components that one uses. And then the time taken to get your environment just right so it's intuitive. There just wasn't enough to make me move.
The first release in all this time that has really caught my eye and made me want to upgrade is Delphi 2007 for Win32. I downloaded a trial and loved it, it was the first time I'd used the new Borland Developer Studio IDE although I've seen it for years in the demos and tutorials. All the new IDE features (code folding, component palette searching, refactoring) made me want to kiss the screen, so I thought I'd put together a list of pros and cons as well as a price so that I could discuss it with the company.
The money wouldn't be the biggest hurdle I'd have to overcome - I'd need to explain why I couldn't move development forward for a particular timeframe whilst I ensured that every application, DLL, plug-in, utility, etc was recompiled successfully and working at least as well as it is now. And then, after all that, we'd be at a stage where the software works exactly the same as it did before I started.
"What, all that time spent and you end up with the same product?", I can anticipate hearing.
But you and I know that it isn't just about that. Time invested there means potentially time saved when we have a much better version of Delphi, an IDE with cool features which supposedly mean I can turn work out faster. Ah, I'm getting them back on side with that one.
So this document, which admittedly was very balanced and not at all as conclusive as I'd have liked (but I was being honest) went to the technical director who, predictably, said, "Doesn't really help either way, does it?". Which was fair. So I posted it on the Developer's Group newsgroups (a UK-based developer's group that we're a member of and that has a private newsgroup) to see what my peers could add to tip the balance. The result was frankly disappointing given that its members and regular contributors are well known magazine authors and conference speakers.
But then I received an email from one of the group's administrators who asked if she could include the document as an article in the next magazine as it would make an interesting discussion. I happily agreed although I had privately thought that if there was to be a discussion, it would have taken place on the newsgroup.
In the meantime, I wanted to discuss it here. I'm going to reproduce snippets of the document below to outline the salient points and then see what you have to add. Do you agree with the points I make, disagree with them, or have things to add to them? Can you tip the balance? My heart wants to move to Delphi 2007 with Software Assurance but my head is wondering if it worth the investment of time and money.
When Delphi 6 was written, there was no Windows XP. We use third-party tools (JEDI) to allow our application to take on the themes supported by Windows XP and Vista. Whilst this particular example is free and the widely accepted alternative, my personal opinion is that the more we move away from third-party support (where Delphi offers the same solution) the better, as it enables future upgrades to be less troublesome.
For many of our third-party components, Delphi 2007 was not available at the time we purchased them. But, in a fortunate turn of events for us, Delphi 2007 fully supports any code written for Delphi 2006 (they called this a “non-breaking release”); this means that most of the third-party components we already own will actually work in Delphi 2007, because they were written up to and including Delphi 2006.
Other reasons to move are not necessarily end-user based, but developer based. In 7 years, CodeGear (formerly Borland) have added dozens of IDE enhancements that would make the life of the developer much easier. Many of these features result in writing faster code, which means things just get done quicker.
Why not move?
Third-party vendors appear to continue to support older versions of Delphi (including v6) because so many users don’t upgrade to the most recent versions.
Tuesday, 3 July 2007
The moving Microsoft standard
When I was first brought into my company to port the software from Unix to Windows, Windows 95 was the latest OS and Microsoft were very proud of it. Although I didn't read any official literature from them at the time, I was already aware from my own use of Windows that there were certain standards to be maintained. Not standards as in quality (heaven forbid), but standards as in consistency. But then, I guess we know Microsoft's record on following the standard.
(Actually I just want to point out that I'm not a died-in-the-wool Microsoft basher, I actually think they have produced some outstanding software, but none of us get out of our chair to compliment people do we, we only complain. Even us Brits).
In "The Windows Interface Guidelines for Software Design" from Microsoft Press, there are sections such as design "consistency" and "forgiveness" and an appendix giving "common navigation...and shortcut keys". This was especially relevant as Microsoft were trying to allow the mouse and the keyboard to be used independently as opposed to having to use them in combination.
I built my software around these common ideas, which wasn't always welcome; Unix, you'll remember or no doubt know, used the [Enter] key for moving between elements on a screen; Windows started to use the previously underused [Tab] key, and left the [Enter] key as the default action key (usually pressing an OK button). This caused all sorts of uproar from our customers who moved from Unix to Windows (usually because their management had wanted them to, not because they'd wanted to!), and on one screen in particular where speed of entry was paramount, we were forced to allow the Enter key to reproduce the effect of the Tab key. It didn't take me long to find how to do this 10 years ago which led me to suspect many people were in the same position.
But I towed the line for the most part and argued the case that "this is how it is done in Windows", and ended the debate. The principle of keeping to a design standard to allow your users to feel comfortable with any software is a good one and although it certainly wasn't introduced by Microsoft, they did make an effort to let developers know it was expected.
So, how is my software doing 10 years on? Well, sadly, it's looking like a Windows 95 application, but given that is deals with mundane day-to-day enterprise tasks, no one is really complaining that the menus or the toolbars aren't covered in colour and pictures. However, this is often a hurdle for the sales pitch and it's laughable how many potential clients sit through our unique selling points or all the items that our software does better than the competitors, and then sit bolt upright when we show them a report with some colours on it, or a screen where a bit of text is highlighted. Usually followed by, "Ooh, I like that; can you customise those colours?".
But my gripe is with the consistency of keyboard shortcuts. And one in particular: Search. F3. Isn't it? It is on our software because in Windows and Office '95, F3 was always "Find...".
Well it still is in Explorer in Windows 2000, XP & Vista (it brings up the File search) and Notepad (brings up the text search). And it used to be in IE5 but in IE6 it brings up the "Search the Web" toolbar which is immensely annoying. Interestingly in IE7, it brings up the page search again like before IE6. Bit of a U-turn. In Windows Media Player, F3 launches the "Search for Media" dialog and in MSN Messenger, it puts the cursor focus into the contact search box. All "find" related.
What about Office? After all it is Office that is actually the one setting the design standards every two years or so, not Windows itself. In Excel, Powerpoint and Access, F3 does nothing, CTRL+F is required to launch "Find". CTRL+F goes way back so I'm OK with that but F3 could have been made to do the same seeing as it is sitting idle. The same CTRL+F keystroke is required in Word, but horror, F3 does something else! Something to do with Autotext that actually either just changes my document or puts a conspicuous message in my status bar that I usually miss.
In Outlook, F3 shows the little Find toolbar, so one out of 5 isn't bad. But wait. What if I'm reading an email and want to search for text in there? F3? CTRL+F? No. F4. F4? But F4 doesn't do anything in any of the other Office programs. And get this, CTRL+F forwards my email. And F3 does nothing so why couldn't they have used that?
This is actually an unforgivable inconsistency from a corporation the size of Microsoft that prides itself in the interoperability of its software. Especially when they have the gaul to produce books on how we should adhere to design consistency.
So now not only does my software not look colourful because I can't keep up with every release of Office, it now doesn't behave like the latest Microsoft software either. So my users are left having to remember the keystrokes for my software, even though I actually set them to MS standards 10 years ago. But then those same users are going to find different strokes even within the Office suite so they've got no hope.
This isn't really a rant just about F3, it's about Microsoft setting a standard and then moving away from it at the next opportunity. The Ribbon toolbar in Office 2007 has split opinion and I can't lend my support to either side because I'm happy with the Office I'm on. But it's a whole new paradigm that users have to get used to. From what I hear, most people like it once they get past the initial fear, but it's a lot to ask people to learn how to use your software, especially when you're the company driving the standard on your own OS. And for us developers to try and keep up, we have to licence the use of the Ribbon? You're having a laugh.
MDI is another concept that MS really pushed to the forefront and my 10-year old software is MDI to the core. They announced some years ago that they would no longer write MDI applications and no longer thought it was a secure model, which is why you now see Word and Excel, etc all open up a separate Window instance for each document/worksheet as opposed to them all being under one parent window like Office 95. Of course you can still switch between them from the Window menu which is a nice touch for those of us who should know better than to get stuck in our ways.
But the real thing that this is about, and what I wanted to ask you, is should we, do we, and how do we keep up with the look of the software. I fall in the camp that I want my software to look native to the version of Windows you're running. To that end, I use buttons that aren't themed in Windows 2000 but take on the common controls theme for XP and Vista. Same for all other controls. And I set my application font to the font of the OS when it runs, so it looks native and not at all clumsy. And in fact this works well, espeically in Vista. A Delphi 6 program running on Vista, still using the default MS Sans Serif font, looks very old. Even with theme support. Change the font to Segoe UI and bingo, it makes a dramatic difference.
However, not all controls are themed, toolbars being one. There isn't a difference between ComCtrl 5 and 6 for these. So that ruins the effect I was getting closer to, where my application doesn't look out of place. I don't want it to look like a Vista or XP app on Windows 2000 (which personally drives me crazy), but some of those controls just don't scale up to allow me to have it both ways.
And of course many people turn the theming off in XP and Vista and go back to Classic; so why should we subject them to the themed buttons when all they want is their old Windows back?
So how are you keeping up with the trends? Are you at all? Have you gone down the route of just designing software that has a look of its own in which case you are your own master, or are you trying to design it so that it fits in? At what point do you let the nice new buttons and other controls creep in, regardless of the OS?
(Actually I just want to point out that I'm not a died-in-the-wool Microsoft basher, I actually think they have produced some outstanding software, but none of us get out of our chair to compliment people do we, we only complain. Even us Brits).
In "The Windows Interface Guidelines for Software Design" from Microsoft Press, there are sections such as design "consistency" and "forgiveness" and an appendix giving "common navigation...and shortcut keys". This was especially relevant as Microsoft were trying to allow the mouse and the keyboard to be used independently as opposed to having to use them in combination.
I built my software around these common ideas, which wasn't always welcome; Unix, you'll remember or no doubt know, used the [Enter] key for moving between elements on a screen; Windows started to use the previously underused [Tab] key, and left the [Enter] key as the default action key (usually pressing an OK button). This caused all sorts of uproar from our customers who moved from Unix to Windows (usually because their management had wanted them to, not because they'd wanted to!), and on one screen in particular where speed of entry was paramount, we were forced to allow the Enter key to reproduce the effect of the Tab key. It didn't take me long to find how to do this 10 years ago which led me to suspect many people were in the same position.
But I towed the line for the most part and argued the case that "this is how it is done in Windows", and ended the debate. The principle of keeping to a design standard to allow your users to feel comfortable with any software is a good one and although it certainly wasn't introduced by Microsoft, they did make an effort to let developers know it was expected.
So, how is my software doing 10 years on? Well, sadly, it's looking like a Windows 95 application, but given that is deals with mundane day-to-day enterprise tasks, no one is really complaining that the menus or the toolbars aren't covered in colour and pictures. However, this is often a hurdle for the sales pitch and it's laughable how many potential clients sit through our unique selling points or all the items that our software does better than the competitors, and then sit bolt upright when we show them a report with some colours on it, or a screen where a bit of text is highlighted. Usually followed by, "Ooh, I like that; can you customise those colours?".
But my gripe is with the consistency of keyboard shortcuts. And one in particular: Search. F3. Isn't it? It is on our software because in Windows and Office '95, F3 was always "Find...".
Well it still is in Explorer in Windows 2000, XP & Vista (it brings up the File search) and Notepad (brings up the text search). And it used to be in IE5 but in IE6 it brings up the "Search the Web" toolbar which is immensely annoying. Interestingly in IE7, it brings up the page search again like before IE6. Bit of a U-turn. In Windows Media Player, F3 launches the "Search for Media" dialog and in MSN Messenger, it puts the cursor focus into the contact search box. All "find" related.
What about Office? After all it is Office that is actually the one setting the design standards every two years or so, not Windows itself. In Excel, Powerpoint and Access, F3 does nothing, CTRL+F is required to launch "Find". CTRL+F goes way back so I'm OK with that but F3 could have been made to do the same seeing as it is sitting idle. The same CTRL+F keystroke is required in Word, but horror, F3 does something else! Something to do with Autotext that actually either just changes my document or puts a conspicuous message in my status bar that I usually miss.
In Outlook, F3 shows the little Find toolbar, so one out of 5 isn't bad. But wait. What if I'm reading an email and want to search for text in there? F3? CTRL+F? No. F4. F4? But F4 doesn't do anything in any of the other Office programs. And get this, CTRL+F forwards my email. And F3 does nothing so why couldn't they have used that?
This is actually an unforgivable inconsistency from a corporation the size of Microsoft that prides itself in the interoperability of its software. Especially when they have the gaul to produce books on how we should adhere to design consistency.
So now not only does my software not look colourful because I can't keep up with every release of Office, it now doesn't behave like the latest Microsoft software either. So my users are left having to remember the keystrokes for my software, even though I actually set them to MS standards 10 years ago. But then those same users are going to find different strokes even within the Office suite so they've got no hope.
This isn't really a rant just about F3, it's about Microsoft setting a standard and then moving away from it at the next opportunity. The Ribbon toolbar in Office 2007 has split opinion and I can't lend my support to either side because I'm happy with the Office I'm on. But it's a whole new paradigm that users have to get used to. From what I hear, most people like it once they get past the initial fear, but it's a lot to ask people to learn how to use your software, especially when you're the company driving the standard on your own OS. And for us developers to try and keep up, we have to licence the use of the Ribbon? You're having a laugh.
MDI is another concept that MS really pushed to the forefront and my 10-year old software is MDI to the core. They announced some years ago that they would no longer write MDI applications and no longer thought it was a secure model, which is why you now see Word and Excel, etc all open up a separate Window instance for each document/worksheet as opposed to them all being under one parent window like Office 95. Of course you can still switch between them from the Window menu which is a nice touch for those of us who should know better than to get stuck in our ways.
But the real thing that this is about, and what I wanted to ask you, is should we, do we, and how do we keep up with the look of the software. I fall in the camp that I want my software to look native to the version of Windows you're running. To that end, I use buttons that aren't themed in Windows 2000 but take on the common controls theme for XP and Vista. Same for all other controls. And I set my application font to the font of the OS when it runs, so it looks native and not at all clumsy. And in fact this works well, espeically in Vista. A Delphi 6 program running on Vista, still using the default MS Sans Serif font, looks very old. Even with theme support. Change the font to Segoe UI and bingo, it makes a dramatic difference.
However, not all controls are themed, toolbars being one. There isn't a difference between ComCtrl 5 and 6 for these. So that ruins the effect I was getting closer to, where my application doesn't look out of place. I don't want it to look like a Vista or XP app on Windows 2000 (which personally drives me crazy), but some of those controls just don't scale up to allow me to have it both ways.
And of course many people turn the theming off in XP and Vista and go back to Classic; so why should we subject them to the themed buttons when all they want is their old Windows back?
So how are you keeping up with the trends? Are you at all? Have you gone down the route of just designing software that has a look of its own in which case you are your own master, or are you trying to design it so that it fits in? At what point do you let the nice new buttons and other controls creep in, regardless of the OS?
Subscribe to:
Posts (Atom)