The Ribbon Control

Now I’m not a major fan of Microsoft’s ribbon control, and our clients have for the most part stuck with Windows XP, and Office 2003, so there has been no real call for it in our applications. However, with the advent of Windows 7, we are getting more and more calls for our application to look more like a Windows 7 and more specifically an Office 2007+ application.

To that end I have been experimenting with the ribbon control in Delphi 2010. And my am I frustrated. This is the buggiest component I have ever used out of the (Delphi) box. I add ribbon groups that disappear (I have found a workaround, by opening the form as a text file and back to form again) Icons initially appeared non-transparent, then started working. Sometimes actions would not have a caption. I’d delete the group, re-add the action, and the caption magically appears. It just seems so fragile. Has anyone actually managed to get anything but a hello world application, using a ribbon control, to actually work. and more importantly, not go nuts in the process.

This is why I protest so loudly at the Delphi pricing. Delphi 2009, touted the ribbon control and generics as two of it’s major plus points. Generics were barely useable until update 3, and then abandoned in Delphi 2009, with new fixes going in Delphi 2010. The ribbon control, I assume, was just as bad in Delphi 2009 as it is in Delphi 2010, if not worse.

Stop releasing new versions every 5 minutes, and fix the outstanding problems. Why should I have to get Delphi 2010 to fix the generics I paid for in Delphi 2009? Why should I now have to find a third-party ribbon control to fix what I paid for in Delphi 2010?

Customer Care

I was browsing Delphi tagged questions in stackoverflow yesterday, when I encountered this question. It’s all about generics in Delphi 2009. Whether they are actually usable. Here are a few clips from the answers :

 

I'm using generics extensively in Delphi 2009, and I can say it's not easy as you are often required to work around an ICE

All this trouble seems to be gone in Delphi 2010

Bottom line: if you want to use them, upgrade to 2010.

 

I have also personally mentioned before that the IDE just doesn’t seem to recognise the existence of generics (try any refactoring or code completion). So basically what we are saying is that if you bought Delphi 2009, and you want to use generics in any meaningful way, you need to fork out more money and get Delphi 2010.

Does anyone else find that disturbing? Let me give you a comparison. Let’s say you have just bought a Dell laptop. It cost about the same as Delphi 2009. The (fictional) Dell Longitude 2009. Among it’s many features, is built-in wifi. When you got the laptop, wifi kind of worked, but the laptop didn’t really recognise it had wifi, and you had to do a lot of manual stuff to get it working. When you did get it working, you noticed in some circumstances, it just refused to work, and in others it only kind of works. You complained to Dell, and they released update 2 and update 3 (some kind of bios update), which made things a lot better, and you were kind of happy. Less than a year later, Dell release the Longitude 2010. It looks like they’re not going to fix the existing wifi problems in the Longitude 2009, but if you have a 2009, they’ll give you a special price on a brand new 2010.

Would you buy Dell again? Would you not expect Dell to fix your Longitude 2009? And if they can’t or won’t, don’t you expect a refund?

I’m not singling out Embarcadero here, it is apparently industry practice. What other industry could get away with it though?

What worries me is that I have to go to my boss and ask to upgrade to Delphi 2010. I am lucky, that I work for a company that has no problems in giving us the latest tools, whatever the cost. And in the grand scheme of things, to even a small company, the price of Delphi is insignificant. However, my boss will definitely ask the question, What does Delphi 2010 give us? I can wax lyrical about increased IDE productivity, and improved RTTI, but at some point I’ll have to add the line. Well, we had a few problems with generics in D2009, but it’s all been sorted out in D2010. What kind of confidence does a line like that instil?

Delphi Generics

Generics was or is one of the flagship features of Delphi 2009. Probably up there with unicode. Unfortunately, I don’t think the time was been put into the feature that it deserves. It feels like a badly implemented third party component. There doesn’t seem to be much in the way of communication with the ide. Code completion doesn’t work with generics. Same with class completion. Why not? Refactoring falls over as well.

This was all annoying, but we could almost live with it. Unfortunately we’ve now got a problem, which means we can’t use generics at all. Most of our automated testing is done with Automated QA’s Test Complete. Since we’ve moved to Delphi 2009, we’ve had a major problem, in that the debug information from our Delphi application was not being read properly from Test Complete 7. Here’s my question about it on Stack Overflow. Automated were baffled. We tried writing small test applications, but we couldn’t reproduce the problem. There was something about our application, Test Complete didn’t like. After months of investigation, we finally came to the conclusion that generics was the problem. Luckily, we had actually refactored some of our code to use generics, so it was easy to go back to the previous version. And hey presto, Test Complete is now totally happy.

Automated are now looking at it. I wonder if it’s a Test Complete problem, or is it generics messing up the debug information in the executable?

Quality?

I’ve been using Delphi 2009 for about a month now, and for the most part I’m happy. Unfortunately that’s only because when you’ve been disappointed so many times, you’re grateful when you get an IDE that doesn’t crash every 5 minutes. Seriously though, so far so good. (one thing is driving me nuts though. I’ll post about it later)

So there are a few bugs. I’m a developer, and I’ve been around long enough to know that every piece of software, however good the process and the people behind it, has bugs. So I’m under no illusions here. While no bugs would be nice, I know it’s not realistic. But here’s my gripe of the day! Why does it take so long to fix the bugs?

Whilst I expect bugs in a product, I don’t expect to wait 6 months after it’s release, for those bugs to be fixed. Some of the bugs I’ve found in TDictionary lead me to believe the code was not tested. Already not a very good sign. But hey, things fall through the cracks, we’re only human right? The thing is some of those bugs are so easy to fix, that any junior developer, just out of college, could find them, and fix them in an afternoon. So why 6 months later, are we still waiting? I don’t understand it?

And it’s not like Codegear don’t know about these bugs. They’ve been reported in Quality Central for a while. Oh and that’s another thing. If you’re going to charge me for your software (fair enough), and then use me as a tester,  please, oh please make it easy for me to tell you about bugs in your software. I have to go to the Codegear website. If I’m lucky, I’ve got my username and password written on a piece of paper somewhere, if not, I have to click on the lost password link. Wait for the email, fish it out from my spam folder. Then I’m not sure what you have to do, because I never got that far. Why can’t I just highlight some code in Delphi, right click, and choose report a bug. Put in a little description, and that’s it? You have my details as I use a registered copy.

As you can tell, I’m impatiently waiting for update 3? Where is it guys?

Generics in Delphi 2009

I've now had Delphi 2009 installed on my machine for about a month, and have been refactoring some code to take full advantage of Generics and Anonymous methods. I really like generics, but am beginning to feel really uncomfortable with the Delphi implementation. It just doesn't feel 100% stable. I get the occasionaly internal error, which then dumps you somewhere at the very beginning or very end of a file, with no indication about what you have done wrong. Try adding the overload keyword to a method in a generic class, without actually overloading the method for example. Code completion is a bit of a mess, sometimes working, and sometimes not. I won't even mention the TDictionary class, which is practically useless, as it is riddled with bugs. Well perhaps not riddled, but there are a few, making it unusable. Try using the enumertors for example.

Why release it when it clearly needed a little more work? When is it going to be fixed?

Component ITunes

Delphi’s strength has always been the VCL, and it’s extensibility. You always got a lot out of the box, but the knowledge that whatever you wanted to do, there was a component somewhere out there that would do it for you was an incentive to use Delphi. I could, and did spend days on the Delphi Super Page, just downloading components and trying them out.

Borland (and now Codegear) have always been careful not to step on the feet of their third party vendors, so always left some gaps for them to fill in. And rightly so. That’s why Delphi was such a success.

Unfortunately, the third party vendor scene has not been as vibrant as it once once. Sadly, the number of vendors producing quality components has decreased greatly since the glory days.

The freeware and shareware scene was also beyond compare. Now almost all freeware and open source components have not been updated since Delphi 7. The Delphi super page sometimes feels like a museum. With the advent of Delphi 2009, this problem can only get worse, because while before, a simple recompile would suffice, now you have to do some extra work.

I think Borland were 100% right in leaving the market open to third party vendors, and stepping back and letting others fill the void. It made Delphi popular, and it made the vendors happy.  But times have changed, and perhaps now it’s time for Codegear to step in, and help it along a bit.

My suggestion is for Codegear to setup an ITunes for Delphi components (you know what I mean!). Somewhere, vendors, developers and Codegear themselves can sell (or give away) quality components. Codegear could approve anything deemed worthy to be on there. There is a lot of abandon-ware out there that could be resurrected and brought up to date for Delphi 2009, endorsed, and offered up by Codegear. There’d be one central place where Delphi developers go for all their component needs.

The remaining third party vendors would be happy, because they’d have another outlet for their products. New vendors would be happy, because they have a customer base ready, and waiting, and hungry for new components.

If Apple can do it with music, why can’t we do it with components?

Catch 22

I’ve just read Marco Cantu’s comments about a few of my posts. (I’m honoured Marco!). The crux of Marco’s comments is that Delphi developers fall in to two distinct camps. Those who want Unicode and those who don’t. Therefore Codegear had to make a choice on whether to make it easy for camp 1 or camp 2.

There are a few problems with this hypothesis.

1. There are more than two camps. I fall under neither for example. I want Unicode. I really do. I wanted (or rather needed) it so much in fact, that I implemented Unicode support using Delphi 2006. I would like to be able to move to Delphi 2009 (after all it is the latest and greatest, and where I can expect the most support, and where I hope migration to 64bit will be easiest), without having a major dip in the quality of my software.
2. By choosing to change the meaning of PChar and String and all those methods that ultimately called Ansi versions of windows functions, what Codegear did was make it difficult for everybody. Those that are not interested in Unicode have work to do, and those that are interested in it also have work. Anybody who’s done the conversion knows that the biggest problems are places where PChar has been used as a pointer to a byte. Buffers and bookmarks in dataset descendents for example. So it’s never just a re-compile.
3. All those who are defending Codegear’s decision, keep saying it’s easy to make the move. It’s x days work, it’s no big deal etc etc. That maybe the case, but experience tells me that making such a change will result in a far greater hit to the testing burden than actual development time.

I’m almost ready with my migration to D2009. It was probably harder (ironically) than most, because my application already was Unicode compatible through use of Widestrings and TNT unicode components, but it still wasn’t that bad. The thing is though I know for a fact that my application has gained a few (only a few mind you, I’m optimistic) bugs. It’s inevitable. And because most of the problems were to do with buffers and pointers, it’s those subtle, “it was ok on my machine” type of bugs. The testers are not going to be too happy. The first thing they ask when they receive a build is what should they concentrate on. My answer this time is everything. I’ve touched every single piece of functionality. Most (if not all) their automated tests are probably broken (I haven’t told them that bit yet!), so not only do they have a lot of testing to do, they have a lot of test code to migrate. And at the end of all this what does our application gain. Nothing. At least those who have Ansi applications can say we now have Unicode support. We can’t, we had that already!

I think Codegear had a dilemma, and quite a few people must have had a few sleepless nights trying to figure out what the best thing option was. Whatever they had chosen, would have caused someone, somewhere grief. Had they gone for any other option, I’d probably be writing a post complaining about it. I’m like that!

Misunderstood. Who me?

My last post generated exactly the type of comments I expected it to. In fact I could have written them myself as I knew what was coming. Here’s a sample, and my reaction to them.

The US are only 5% of the world population. That means that 95% of all Delphi users need Unicode.

I never said I didn’t want unicode. In fact our application is already Unicode compatible, but I still wanted reference counted unicode strings. I just didn’t want my existing code to break. I would have preferred the choice of when I decide to move to UnicodeStrings to be in my hands, and not forced upon me. (well not forced, I could always stick with D2007, but you know what I mean)

---

I adapted my app within 2 or 3 hours.

Great, you now have a unicode version of the Hello World application. In the real world, applications are a little more complicated, and take a little longer. If you managed to upgrade your application in 2 or 3 hours, your application is either very small, or you’re a genius!

---

...why should I write new code with special TEditW lines - who needs pure ANSI code today?

Ok, why should the quality of my code suddenly take a nose dive, just because of a compiler upgrade? And again, I’m not arguing against Unicode and in favour of Ansi. I’m just questioning how the move was made.

---

You don't think this (Delphi 2007 compatibility switches) has been considered, do you?

I’m pretty sure it was, or at least I hope it was. Was the right decision made? I don’t know, but I’m pretty certain from a technical point of view, the right decision would have been the least number of breaking changes as possible. On the other hand, this would definitely have pushed the release date back quite a bit, so you also have commercial considerations. I’m a technical person, not a salesman, so I ignore the commercial considerations. I’m sure Codegear can’t afford to.

---

Apart from all the above comments, I got quite a few agreeing with my point of view. These actually surprised me more than the ones above. I originally thought perhaps I was being a little harsh, but it seems I’m not the only one slightly annoyed.

 

Anyway, the actual conversion is going pretty well. Biggest problems have been third party components. I now have an application that compiles, but ironically, while it handled Unicode with no problems in Delphi 2007, the Delphi 2009 version is struggling. We need to do a lot more work to get to the same quality point we were before. We will have touched probably 70-80% of the units. That’s a major test burden in of itself.

And the thing is, in the eyes of our users, our application hasn’t gained a thing.