TPersistent.com

I’ve made no secret that I loved CodeRush for Delphi.  I still mourn the loss of Mark Miller from the Delphi community.  CodeRush was, by no means perfect.  Some of the issues I had with it may have been due to Delphi bugs, undocumented APIs, or bugs in CodeRush itself.  All I know is that I was much more productive with it, than with the standard IDE, and unfortunately, that still holds true today.  CodeRush, circa 1997 has great code navigation and smart templating.  Compare that to XE2 today:

If you create an FMX application and in the main form, type in pr and hit Ctrl+J to use the template this is what you get:

procedure MyProcedure();
begin
end;

What is in Italics is selected so you can replace it.  This leaves a little to be desired.  For one thing, pressing Ctrl+C to invoke code completion won’t even do anything, so the code won’t compile because there isn’t a preceding method prototype.  Add the fact that the entire unit is a form and the method generated by the template is not even for the form class, and it’s almost comical.  The template appears to be completely ignorant of the context in which it was expanded, and you might expect a modern IDE to ask for the scope of the new method, and automatically insert the declaration into the type or implementation section using the appropriate scope.  This kind of functionality actually makes you wonder if anyone at EMB is dogfooding the product.

Then there is code navigation.  You can use the Ctrl + Up/Dn Arrows to jump between method declaration and implementation.  Sometimes it gets a little confused if you use overloaded methods, but this works pretty well, but how do you jump to the implementation or interface section?  The standard IDE doesn’t provide such functionality, and this is a common activity when creating or changing method prototypes.  So common, in fact, both CnPack and GExperts have provided this functionality in additional to method searching.  As someone new to the IDE, you likely wouldn’t know you have to install third party products for such basic functionality, and when looking at the purchase price of XE2 it seems you get a whole lot less, even though these third party add-ins are free.  The downside to these tools is that they also use their own code parsers, so many of them have a limited understanding of new language features, and require even more code to continuously run in the editor to provide the additional capabilities.  I really wish EMB would provide a CodeDOM for the development of such add-ins and incorporate some of this functionality into the standard IDE.

The examples I’ve given are only the tip of the iceberg.  I have QCed a number of these issues, including bugs in code completion that result in AVs at run-time because it inserts invalid code.  Since then, XE2 has shipped, and 4 updates have been issued, but the bugs I reported in QC still remain.

Software is one product in which quality matters more than most.  It affects the day to day experience of the user.  While quality has definitely improved in the Galileo IDE since CodeGear was spun off, and has continued under EMB, IMHO there is still much to be done.  I often wonder what the state of the IDE would be, if the D7 IDE had not been replaced with the Galileo IDE, and instead all that effort for the new IDE and to add new features like UML modelling which few people use, had been put into making the existing IDE even more RAD.  When the stock IDE has the same basic functionality it had 15 years ago when it was branded as RAD (where R stands for Rapid), can you still call it RAD 15 years later in computing time?

Personally, I would have rather have better IDE navigation, templating, and refactoring productivity features than half baked features like ErrorInsight, which gives so many false positives, I normally just ignore it.  I certainly hope that EMB considers an a la Carte pricing model at some point, and concentrates of fixing issues with the IDE as well as fleshing out FMX for the next release.  For now, I’ve passed on the XE2 update offer for my personal use until some of my QC issues are fixed.  Perhaps QC votes should be changed into dollars, so you can vote with your pocket book

If it comes down to a question of doing it well, or not doing it at all, sometimes less is more.

As I mentioned in my previous post, I’m starting to play more with FireMonkey, and one of the first things I noticed when writing an application, is that despite 4 updates there are still no action components.  Although I only started using actions long after they were first released, their benefit has been made obvious to me time and time again.  In my current project I use quite a bit of logic in my TAction.OnUpdate events.

I missed them in .NET, and now I am missing them again with FireMonkey.  If you’re filling out the Delphi survey, you might want to put in your vote to include TActionList, TActionManager, TPopupActionBar, TActionToolBar, and TActionMainMenuBar.  All of them are suspiciously missing in FMX, and I would venture that no self respecting Delphi developer would embark upon a project without the core tools we’re used to using in the VCL realm.  Certainly this is one other requirement for “porting” a VCL app to FireMonkey.

Now to get back to working on that FMX app…

I have finally started re-factoring hcOPF to support FireMonkey and Win64.  Win64 was a breeze, but supporting FMX is proving to be a bit of a challenge.

If I was EMB, I would be trying to make FireMonkey a write once compile on many platforms solution, and it is across Linux, Mac OS/X and Windows AFAIK, if you build an FMX application.  However, I would venture that most customers are looking to port their existing VCL codebase to access more markets, or at least leverage their existing knowledge, and might be a little hesitant to bet it all on a newly released UI framework sold and supported by a single vendor (especially after CLX).

All developers know, changing code tends to break what once worked, especially when you introduce more conditional compilation (check out my QC request 94287 to make conditional compilation easier to use).  To accomplish this end, the API usable to FireMonkey applications needs to have as much in common as possible with even VCL for Windows applications because at some point a developer will use code to manipulate the controls.  If it’s possible to use the same code for both platforms, you’ve saved in not having to maintain functionally duplicate code and in dealing with conditional compilation.

The ideal scenario would be to be able to specify either a FireMonkey or a VCL form DFM in a conditional directive, and have all the UI code shared (or minimal conditional compilation).  Of course, if you want to use the advanced functionality available in FireMonkey, perhaps this approach isn’t viable.  If you just want to target Mac OS/X without having to re-write your VCL application forms, and are using FMX for basic presentation of data, this would be ideal!  You wouldn’t have to invest the same effort to determine the merits of FireMonkey as a UI replacement for the VCL because you wouldn’t need to keep two separate UI source code trees in sync while FireMonkey matures.

So far, with my brief exposure to FireMonkey with XE2 I can see a number of problems in achieving the Write Once Compile for Many Platforms concept.  FireMonkey uses .Text instead of .Caption for some control window captions (ie: TGroupBox).  So while the control class may be the same, even some simple UI code cannot be shared with a VCL application.

Even non-visual code may be a challenge to re-use.  For instance, I use GetTickCount() to time activity in hcOPF.  I want to keep hcOPF compilable for users of D7 and above.  I personally feel that my coding productivity was higher in D7 with CodeRush than the Delphi XE with GExperts and CnPack.  Part of the reason for this is the code parsing the IDE performs in the main thread.  Type in Begin incorrectly, and you can be waiting for 10 seconds while the IDE tries to figure out what is going on.  That’s pretty sad on a 6 core system…but I digress.

GetTickCount() is implemented as an inline function in the implementation section in the System unit for MacOS and Linux, and the Windows implementation is in Windows.WinAPI.  Not a big deal to add a few {$ifdefs} to handle that, but GetTickCount() as defined in System is not accessible to other units.  So in order to use it, you will have to copy the implementation from System, and expose it.

From what I have seen of XE2 Update 4, FireMonkey is still not usable from a performance standpoint for replacing a normal VCL form. On my 6 core system with a Radeon 4250 the main form appears and you can visibly see the contents of the form background and content being rendered.  In this case, the form is just 4 edit controls in 2 separate group boxes using hcOPF Object Binding to populate the controls.

I think FireMonkey is a great concept, but adoption would be faster with an API more consistent with the VCL, and I think FMX has a long way to go before it becomes a viable replacement for the VCL and X platform Delphi becomes a true reality for more than the most trivial application written from the ground up for FireMonkey.

This weekend I went to install Delphi XE2 with Update 4 on my new development machine.  I had previously installed XE2 on my dev machine at work and in a couple VMs.  I upgraded my dev machine @ work to Update 4 on Friday, and then today, attempted to load XE2 Update 4 on my new dev machine at home, only to be told that I have exceeded the licensing limit.  In order to get the limit increased I have to email support.  It’s the weekend, so now I cannot install XE2 and do any work.

I called the support line for Canada, and of course the office was closed so I submitted a web request for technical support (case 00253157).  Fortunately, despite the inability to register XE2 EMB has allowed 14 days usage, so I’m not dead in the water.  It just nags you to register every time you start the product.  I’m sure this is thanks to all the XE2 “updates” that have required us to uninstall the previous version.  I’ve uninstalled and removed the registry settings (perhaps that was my mistake).

This kind of anti-piracy policy to me, is like hand gun registration.  The real criminals don’t register their hand guns, so it doesn’t prevent anything other than to make it more difficult for an enthusiast to own and use one, and definitely more annoying.

Even though I have previously blogged about DealFind leaving their customers high and dry when the vendor fails to render the service promised, this deal is just too good to pass on, and NAPA has a decent rep….