The Ribbon Control Update

A little update to my previous post. Most of the problems I have encountered can easily be fixed by viewing the form as text, and then going back to the visual form. It’s almost usable. Still a pity though.

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?

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?

C# Native Compiler

I was wondering the other day about all the (failed) attempts by Borland/Inprise/Borland/Codegear/Embarcadero (that list there says a lot just by itself) at diversifying their native Delphi compiler. You had Kylix (Delphi for Linux), Delphi for .NET, and C# Builder. All of them not really what you would call successful. Now they are working on a cross-platform compiler, which will be the next version of Delphi. (I still don’t get why they think this is more urgent that a 64-bit compiler)

Has anyone ever contemplated a native C# compiler? I don’t mean something that could take existing C# projects and compile them for Win32. Delphi for .NET showed that the two platforms are just too different for that to ever work in either direction. No, what I’m thinking about is a C# native compiler built on the VCL and the Delphi IDE. I think we all agree that there is a place for native development. There’s a load of C# developers out there though, who would never contemplate Delphi, but if they needed to write some native code, they would certainly look at a C# native compiler.

If that worked, it would definitely save Delphi. As long as the VCL was alive, and you had the same kind of compatibility you now have between C++ builder and Delphi, then Delphi would be back in the limelight.

Just a thought.

Delphi is Dying

Don’t you just hate those Delphi is Dying blog posts? I do? We have been bombarded by messages of doom since about Delphi 4. “Delphi is dying” they scream. “No it’s not”, we counter. “It’s alive and kicking”.

The problem is, I think they finally may just be right. Now I’m a big fan of Delphi, I have been since Delphi 1 (and if you count Turbo Pascal, then a lot longer still), but if I’m beginning to despair, then what hope is there? It’s got absolutely nothing to do with what other people are saying. It’s just a feeling I get from trawling the internet every day looking for Delphi related stuff. There used to be a time when you needed something, you googled it (probably, yahooed it in those days), and you’d get tonnes of hits with sample code, downloads and documentation galore. What do you get now? Almost exclusively you get abandon-ware. Code that hasn’t been updated from Delphi 6 or 7. Half finished components with no, or poor documentation. I guess this didn’t happen over night, but up until Delphi 2009, you’d find some Delphi 5 code, compile it (in say Delphi 2006), and you’re off. Now, with the unicode changes in Delphi 2009, you invariably have to work hard to get any code to compile and work properly. Rather than moan about it, I should perhaps give back to these open source projects, and post my changes somewhere, but to be honest, a lot of the code is so half baked, that it’s just not worth it. You need to not only fix the unicode problems, but do a whole lot more to make anything worthwhile.

 

No doubt, I’ll get a few comments regarding how great Delphi 2010 is, and I won’t disagree. This post is not about how good or bad the IDE is. You can do anything with Delphi today. Sure it has some deficiencies, but what language/platform doesn’t? On the whole though, you can produce fast, compact and useful applications with Delphi. But that’s not the point. The point is that developers are abandoning it in droves. I have no scientific data to prove or disprove that statement, but I do have a feeling. It’s beginning to feel like a ghost town. I’ve just woken up, and realised everybody’s left.