Upgrading to Delphi 2010

While the next major release of the application I work on will no doubt be written in C# (unless we get a 64-bit Delphi, then I have something to argue my case with), for the short-term, we will continue using Delphi. To that end, I like to keep up with the latest version (not always sure that’s a good idea, but anyway) so we recently got a copy of Delphi 2010 to see how easy the upgrade would be.

Not so long ago, I moved from Delphi 2006 to Delphi 2009, so I thought this upgrade would be a walk in the park. There should be no breaking changes. I would need to change a few defines, but that’s about it. And initially that was the case. In no time at all, I had upgraded our third-party components, made the necessary changes to include the new compiler version (more about that in a later post perhaps), and I had the whole thing building in no time. I ran it and disaster. Well it seemed like a disaster. All the fonts of all the menus, both the main menu and all popups were both the wrong font, very large (some the size of the monitor) and skewed. I checked the components in question, and yes the font property was basically garbage. I checked the DFM file, and everything was correct.

Now I have to add that we use some old DevExpress components for our menus. We never upgraded them as they did a complete rewrite of their grid component at the same time, and we had too much invested in the old one. Anyway, we have faithfully updated the source as and when needed. The unicode changes were perhaps the biggest challenge, but not too difficult. Now this! What was wrong?

Something was changing the font. I delved into the source for the components, and zeroed in on the following few lines.

var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(TNonClientMetrics);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0);
  Font.Handle := CreateFontIndirect(NonClientMetrics.lfMenuFont);
  ...

Now this code hasn’t changed since we compiled it with Delphi 2009, so I delved into windows.pas, and found the record that TNonClientMetrics ultimately points to tagNONCLIENTMETRICSW and down at the end, the following line.

iPaddedBorderWidth: Integer; //Requires Windows Vista or Later

Aha, I’m working on Windows XP. I checked the same record in Delphi 2009, and that line was missing. So sizeof was returning 4 bytes extra in Delphi 2010 than it did in Delphi 2009. I confirmed this by trying the following

NonClientMetrics.cbSize := SizeOf(TNonClientMetrics) - SizeOf(NonClientMetrics.iPaddedBorderWidth);

Yes, everything back to normal. Obviously, the code should check for windows version and return the size accordingly, but some kind soul has done that work for me, and added a static method, sizeof, to the record. So the code becomes

NonClientMetrics.cbSize := TNonClientMetrics.SizeOf;

The sizeof static method checks windows version and adds or removes the extra 4 bytes accordingly. I hate breaking changes like these, but whose fault was it. Delphi 2010 or Microsoft?

Productivity versus Excitement

Many of the commentators in my two recent posts pointed out that the IDE additions and fixes in the forthcoming Delphi 2010 will increase productivity. I have no doubt about that. There’s one in particular I can see saving me quite a bit of time, and that’s the uses units. I use that little tool all the time, and could never understand why it automatically always put the unit in the implementation’s uses clause by default. Why can’t I choose? Well apparently now I can.

One particular comment went on to say that compiler changes, the thing I said might just excite me, could in fact decrease productivity. It takes time to learn new stuff, and if you are spending more time learning, than actually doing things, then you’d not getting things done.

That got me thinking about the Microsoft world, and how it seems that you hardly have started looking at one new technology, before it’s superseded by another. You’ve just about got your head around Winforms, and they spring WPF on you, then you jump on to that bandwagon, and suddenly it’s Silverlight out of the browser that’s the new in thing. Oh wait a minute, WPF and Silverlight doesn’t seem to be doing so good, perhaps we should stick with Winforms. Same on the web development side of things. You start with ASP.NET, get comfortable with ViewState and postbacks, and bam, they bring out ASP.NET MVC and tell you to forget all that (Actually they say they’re keeping both, so you need to decide which is for you). To make things worse, they offer you Silverlight as well. It’s the same wherever you look. Linq to SQL? Well apparently Microsoft now prefer Entity Framework. Well they did. I’m not quite sure anymore.

So yeah, all these new innovations to the language and new technologies do have an effect on your productivity, especially if you are trying them all out. The thing is, it’s human nature to want something new and shiny. Look at mobile phones. Most people use their mobile phones for making and receiving calls and that’s it. Oh, they might try a few of the new features when they first get the phone. Maybe take the occasional photo with their phone, but for the most part, they just make calls. So why do they change their phone every 6 months or so? The phone they had 5 years ago still works great for making those calls. The phone manufactures know it’s human nature to always want the new model. So they oblige and keep churning them out.

Microsoft also know that they can’t just rest on what they’ve got. They’ve got to keep their audience excited. Keep throwing as much new exciting stuff as is possible to keep them coming back for more. So while I agree, I’m as productive as a Microsoft developer who is using C# and Visual Studio, I admit I do go green with envy when that get some new toy!