FireMonkey vs. VCL
Monday, March 26th, 2012I 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.