We can expect ‘frequent and regular FireMonkey updates’

sayeth the new Delphi/RAD Studio project manager, echoing both a previous statement of his and similar words by Michael Swindell. Well, we’ll see about that, won’t we? From where I’m looking, FireMonkey is doing an excellent impression of being another Delphi for PHP. Maybe that’s unfair – it’s not like the designer crashes all the time. Rather, the problem is that the framework is no where near ‘finished’ feature-wise. To put it bluntly, FireMonkey in its current state isn’t good enough even for writing a Notepad clone (I know, because I’ve been trying). You can check out Herbert Sauro’s blog for various details (here, also a follow up post here). For my part, here’s a highish-level list of missing features and dubious coding practices, written from the POV of FireMonkey being a VCL substitute on the Mac (since on OS X, that is what it is):

Stuff missing

  • Actions and action lists – I personally found this omission a major disappointment.
  • Frames. [*]
  • Keyboard handling beyond the very basics. E.g., TForm doesn’t have a KeyPreview property and OnKeyDown/Up events, even though implementing them would be a doddle (well, I say that – can the person working on TCommonCustomForm.KeyDown please be told of the existence of case statements?). Also, looking at the source, someone started to port the CM_DIALOGKEY/CM_DIALOGCHAR system (again, something that shouldn’t be difficult, so long as you aren’t fixated on recreating the Windows API message loop), but abandoned the attempt half way through. If you’ve never written a custom VCL control, talk of CM_DIALOGKEY is probably gibberish, but a practical implication is how the Cancel and Default properties of TButton don’t work (be warned the special handling of the ESCAPE key by TCustomCommonForm itself can fool you into not seeing this at first).
  • Any ‘large fonts’ setting on Windows is ignored, and I haven’t found a decent workaround. Another WTF omission for me.
  • Printing on the Mac – there’s stubs but nothing else. In fact, printing on Windows doesn’t work for me either – by the time StartDoc gets called, it fails. Much of the implementation for FMX.Printer.Win.pas has simply been copy and pasted from the VCL TPrinter code. That in itself wasn’t a bad idea, however the splitting out of an abstract base class has necessitated a bit of refactoring which hasn’t been tested properly – try accessing Printer.Fonts without calling Printer.ActivePrinter first, for example, and trace through to find the cause.
  • Property/method reference documentation. In fact, this absence is universal to all the things new to XE2, FMX or otherwise. This is exasperating, and worth repeating: after all the complaints, Embarcadero release a new version with barely any reference help for even the simplest new thing. WTF were the doc team doing for two years? It’s not like they’ve invested time in a DExplore replacement, or fixing blatant usability bugs in the XE help (e.g. the checkbox for hiding C++ declarations not working, and how previously separate Delphi reference entries have been combined into mini-essays, causing the typical user to think F1 brings up useless results when it actually isn’t). The lack of documentation for the new stuff us then made worse by unit scoping (i.e., the prefixing of standard units with a ‘namespace’ – something in itself I quite like BTW), which is rarely acknowledged by the help files, and sometimes confuses them.
  • A TRichEdit-type control. As the FireMonkey TMemo is buggy as hell, and writing a FireMonkey TRichEdit will require a level of dedication far higher than most other controls, I don’t expect to see one any time soon. In fact, given there’s so much work to be done across FireMonkey generally, I think it would be a waste of time for Embarcadero to devote resources to a TRichEdit implementation of their own – if FireMonkey becomes good enough for real work, then a third party or two will come along to fill the gap.

Dubious coding styles and interface decisions

By ‘dubious’, I mean relative to FireMonkey being a core standard library going forward, though frankly, I would be inclined to criticise some of these things even when found in a custom visual framework developed and sold by a talented indie:

  • The Caption property is now Text… except when it isn’t (TForm still has a Caption property; TStringColumn has a Header property).
  • The FireMonkey TFont.Size property has a slightly different basis to the VCL TFont.Size property. Why so? The ‘points’ used by the VCL were already device independent.
  • The Margins and Padding properties have had their meanings switched over, again causing needless confusion.
  • For a would-be core standard library, there is an irritating laziness about aspects of the FMX source files’ coding style. For example, instead of declaring virtual protected methods whose sole role is to raise events, events are raised directly, sometimes even by child controls.
  • Naturally, the unit-wide visibility of ‘private’ sections is liberally exploited, allowing a tight interconnection between classes that is impossible for descendants to hook into. May I suggest a policy that requires use of ‘strict private’…?
  • A case in point: TTreeView has no OnExpanding/OnExpanded events, which means you can’t ‘lazy load’ tree nodes, amongst other things. If TTreeItem.SetIsExpanded were virtual, this could be worked around. However, it isn’t, so you’re left with editing the original source if you want this functionality.
  • By default, no control has the focus when a form is first shown. This contrasts with the VCL, where the first tabable control is given the focus if nothing else has explicitly been set up for it. Perhaps this was thought better behaviour, but it has the big drawback that you have to remember to explicitly set the ActiveControl property of a form, something that the implementors of InputQuery (for example) forgot about.
  • The forms CreateMessageDialog create are just ugly, sorry – they get a tiny font, massive, non-standard icons, and don’t look anything like standard message boxes on any of XP, Vista/7, or OS X. The least the maintainers could do is to add a lighter background to the top two thirds of the form… (Also, while we’re on the subject of small fonts: the Vista/W7 standard is 9 pts, not 8. OS X seems similar to my eyes, if less consistent, but the FMX stock styles appear to use 8 pts, or the nearest equivalent.)
  • Much of FMX.Dialogs.pas and its support code in FMX.Platform.Win.pas has been copy and pasted from Vcl.Dialogs.pas. Like with the printers situation, that isn’t so bad in itself, but I wonder whether it would be better to redo the interface of the dialog components to strip Windows-isms. (As an aside: TPageSetupDialog – apart from only being implemented on Windows, and with an interface that hasn’t been adapted at all for cross platform purposes – causes a weird bug when created prior to the application’s main form being completely initialised: the form is not foregrounded when first shown. The workaround is to only instantiate TPageSetupDialog when required.)

If you’re reading this and thinking of saying ‘have you QC’ed that?’, don’t bother – I’m not a beta tester. I may QC non-FireMonkey things, which are at least genuine bugs or oversights (see what TZipFile writes in terms of date/time stamps when running on a Mac, for example). The FireMonkey issues, in contrast, stem from having released something on the pretence it is a workably ‘finished’ product when it patently isn’t. Until it receives the updates promised, don’t fall for the line it is a ‘version 1.0 product’ (‘it’ meaning FireMonkey – 64 bit seems to be another, happier matter), because that’s a lie as things stand, and a stupidly short-termist lie at that – you’re being asked to pay good money for the privilege of seeing a mere technical preview of a ‘version 1.0 product’.

[*] Admittedly, this one I’m not too bothered about myself, though if and when FireMonkey acquires frames, reimagining them on the lines of VB/WinForms-style user controls would be nice (unlike VCL-style frames, VB/WinForms user controls keep sub-control references and event handlers private).

30 thoughts on “We can expect ‘frequent and regular FireMonkey updates’

  1. What surprises me most is how many of the obvious issues managed to get through the external beta testing. I suspect that many who signed up to be beta testers did no such testing. So long as the updates appear I am hoping it will all wok out in the end.

    • If you Google, you can find leaks of the release notes for the various betas which indicate there were a lot of issues to resolve even before the stage of renaming the old VGScene identifiers into the more VCL-like FireMonkey ones. Turning VGScene into FireMonkey just needed more time.

      The underlying non-technical problem in my view is the rigid 12 month release cycle. This Embarcadero have stuck to like glue, possibly because of the nature of the SA contracts. Combine an apparent fear that one headline new feature is not enough for a major release, and you get situations like the current state of FireMonkey and D2009 (even D2010?) generics.

    • You’re assuming these issues were not raised or logged or discussed during beta testing. I expect that would be a foolish assumption. At the end of the day, Embarcadero is responsible for the product they release, not beta testers.

      • Jed, that suggests the company ignored the bug reports which I find difficult to believe. However it was well known among the original vgsecene users that the original framework was buggy and feature incomplete (the forums can still be read). I just hope the updates fix most of the glaring issues.

      • “that suggests the company ignored the bug reports which I find difficult to believe”

        Is it? If VGScene was as buggy as you say, then I guess there were just other priorities.

  2. The 3d and 2d hardware acceleration are also rather fragile and with blunt simplifications, signs of either a quick hack job made in a hurry, or a job made by an inexperienced team. They definitely had some experts working in FMX though, making some portions look like out of place high-tech magic, but not enough.

    The mess of private abuse is nothing new, it may be far more pronounced, but it has been a recurring issue with the VCL when new components come out.

  3. After reading you post I recall that I had the same feeling when Delpih4PHP was released for the first time.

    Even after so many iterations of D4PHP (now RadPHP) the underlying VCL4PHP is still very buggy and tends to generate a lot of go-in-between code!

    • Alas, but this is long-standing issue – even the VCL’s common control wrappers when originally introduced back in D3 were remarkably poorly coded in my view, and must have caused more work in the long run (the modern Vcl.ComCtrls.pas is enormous, despite not actually implementing any controls itself). Cf. Contnrs.pas (D5), TCategoryButtons (D2006)…

  4. People are reading too much into it. VGScene was buggy from the start. But it was a small (and the only?) player of its kind so people kinda accepted it as it is. EMBT bought it and being a big company they had to deal with quality much more seriously. Unfortunately I think that the lack of resources shows itself. You simply cannot have such a mess if you had a big enough of a team …

    • “You simply cannot have such a mess if you had a big enough of a team”

      I completely disagree – simply chucking bodies at a problem doesn’t solve anything. What was needed was more time. If the promises of regular updates (preferably breaking – keeping DCU compatibility would be utterly pointless) are kept, that time will be found and paying XE2 customers won’t have been cheated at the end of the day. I hope that will happen, but I don’t expect it, given past form.

  5. Don’t forget, it’s very short since Embarcadero bought KSDev and they certainly run out of time.

    I much prefer them to ‘release early and often’… instead of holding back!! Maybe they should have stated more prominently that it’s not yet production ready. But at least they said it’s a 1.0 product (well, 0.1 would have been more accurate;)

    • “I much prefer them to ‘release early and often’… instead of holding back!!”

      Well I don’t. I’ve paid for a technology preview on the pretence it was a working product. Suffice to say, I’m glad I didn’t purchase SA at the same time.

  6. I remember having to fix code in Borland/Turbo Pascal 7’s DOS equivalent of the VCL (forget what it was called…)

    But I shouldn’t overestimate how many people Embi has working on Delphi.

  7. My opinion is that firemonkey should be expected to be like this. It is after all a first release of a new framework.

    I disagree that you can not write a notepad clone in it. Okay, so there are no actions. Fine. And there is no printing. So a notepad without printing.

    I agree with you about lots of things; If firemonkey forms aren’t “scalable” yet, then they darn well should be. It should be possible to have a form organically scale, making it 3 or 5 or 350 percent bigger than it was designed, without any issues. Otherwise, what was the point of the GL/DirectX thing. I would expect that scaling, and “run the app with everything including fonts x% larger” would become a standard feature in FMX, soon, if not already.

    I hear the air getting let out of your over-inflated expectations. Good. Now that we have the same (low) expectations, I think that the next few FMX drops can only improve FMX’s future prospects.


    • It is not a ‘first version’ in any sense beyond the fact the yearly release cycle meant it had to be publicly released. A ‘first version’ in a meaningful sense is XE2’s 64 bit support, along with the non-FireMonkey parts of the OS X targeting (e.g. the RTL’s Objective C bridge), both of which appear plausible contenders for ‘real work’. As it currently stands, FireMonkey is frustrating just to play around with, let alone use in anger. Oh, and did I mention the near-complete lack of reference documentation? I feel an idiot for semi-defending them over the help not so long ago.

      “I disagree that you can not write a notepad clone in it … So a notepad without printing.”

      Er, so you can’t write Notepad in it then. And this from a supposed ‘next generation business application platform’.

      “I hear the air getting let out of your over-inflated expectations”

      ‘Over-inflated’ in the sense I expected it would be somewhat finished? Yeah, whatever. It is their own product’s chances they are pissing up the wall though. And, let’s not forget, it’s not like they don’t have previous. Doesn’t the hiring of one ex-Borland manager after another instill confidence? From the people who brought you C#Builder and Delphi 8, and perhaps most relevantly, C++BuilderX.

      And yet… I am still hoping (if hardly expecting) the promised regular updates to necessitate retracting this post.

  8. I’ve just played around with the XE2 trial version for a couple of hours.

    Sad to say, I tend to agree with the assessments in your post here, Chris.

    It seems buggy, and half baked.

    A couple of things:

    1) The visual form designer: Ctrl+C/Ctrl+V for copying components only works sporadically. (Buggy)

    2) The visual form designer: Components “attach” themselves to each other in random ways, so that when you move one component, one or more other components will move with it on the form surface. (Buggy)

    3) The visual style editor: It’s not interactive. The only “interactive” feature, is that you can select the main style on the canvas. But you cannot click on sub-elements of the styles to select them. To do this, you need to manually select the sub-element by it’s name from the list on the right hand side. (Unfinished)

    4) The visual style editor: Redraw problems. When you alter properties of a style, the visual appearance of the style on the canvas is not always updated accordingly, and you have to move or resize the style element in order to get the needed re-calculation and redraw. (Buggy)

    5) The visual style editor: No right click menus at all. Meaning that you can not interact with elements in the editor, and perform actions on the elements by selecting them and using right click. (Unfinished)

    I think i can say for sure, that I will not end up using this technology for any kind of production work in the near future.

    It’s not correctly done, and it is unfinished.

    I wonder why Embarcadero even found it worth including this in the release. If anything, it should have been included only as a technology preview.

    Also, they should not have tried to recreate so many of the standard VCL-controls for this release. They should have focused on getting the core framework totally right, and maybe included a small subset of example components, for the preview.

    Instead, they have focused on getting everything done, with the result that almost nothing of it works the way it is supposed to work.

    It MAY be possible for Embarcadero to patch this up into something usable in coming releases, and to regain the confidence in the technology, which they now partially have lost by releasing it in this buggy state.

    Personally, I’m not holding my breath.

    (Another thing which should have been considered, was to include this as a subset of the VCL framework, making it possible to mix FireMonkey features with ordinary VCL-applications. This would have made it possible to use this technology for smaller parts of application systems, and thus using it only for the things for which it was ready. This would have aided a more gradual adoption of the technology. By keeping it totally separate from the ordinary VCL-technology, they are blocking this migration path.

    Oh well. As long as it does not work properly, I guess it does not matter much anyway…)

    • Well, the ‘large range of controls’ is somewhat less than it appears once you can see the source – things like TToolBar are just an ordinary container control that has a certain style defined. I’m also not sure about your mixing and matching idea – FireMonkey has a fundamentally different basis to the VCL. Moreover, one of its main rationales is enabling cross compiling to target the Mac, for which playing nice with the VCL is irrelevant. Any time spent on FireMonkey-VCL interoperability would be time better spent on FireMonkey itself IMO.

      • Yes, maybe you are right.

        But, remember 95% of all Delphi users are maintainers of legacy VCL-based systems.

        It takes a huge leap of faith to start any kind of rewrite of such systems using the new FireMonkey technology.

        It would take a smaller leap of faith to start by adding some FireMonkey based features to the existing application systems.

        I realize it’s extra work. But I think maybe it could have been worth the effort, in order to get a certain adoption rate for the new technology. Now, maybe they are faced with an adoption rate of ZERO, because of the unfinished state of the product, and because of the intended water tight barrier between the two technologies.

        I would have prioritized in the following way:
        1) Making the core framework rock solid.
        2) Making the IDE-support for the framework rock solid, including form editing and style editing.
        3) Making it possible to use FireMonkey features within existing VCL-based systems.
        4) Making it possible to create FireMonkey-only applications, with cross-compilation support.

        In other words, catering to the existing Delphi users first and foremost, and then adding cross compilation as a fourth priority after that.

        I think it’s a trap trying to revolutionize, when they really should be trying to evolutionize.

      • When you put cross platform last, you’re ignoring the fact XE 2’s OS X targetting is for precisely ‘existing Delphi users’. If you’re desperate there’s FPC/Lazarus, but that combo produces applications that look rather less ‘native’ than XE 2/FireMonkey ones to my eyes, even though FireMonkey is all custom drawn.

        “and because of the intended water tight barrier between the two technologies”

        I still think you’re looking at this the wrong way. Despite having *much* more modern underpinings, the surface of FireMonkey is very much in the Delphi-as-VB vein. In fact, given the absence of more ‘advanced’ VCL features like actions and gestures, I’ve found playing around with FireMonkey very much a ‘back to the future’ experience, like knocking together a VCL application in the earliest days – you add a button, you double click it, you end up putting a load of code in the generated OnClick handler, feel inclined to directly invoke other control’s event handlers, and so on. Naturally, the near complete absence of reference documentation impairs the experience very much – but the basics aren’t alien at all, unlike (say) the XAML designer in Visual Studio.

    • I ahve spent time in XE2 Datasnap. It is very bad. Ufinished, Untested, and very buggy. It is a step backwards from Xe 2010 I have complained to management but no one answers the Emails or cares. This is the sign of a company that is all but finished. Its a great pity. Delphi was the greatest vertical app development tool and we had such high hopes for XE2. Forget about 64 bit and FM. They can not even get the basic 32 bit parts right. – AND they dont give a damn. XE2 was released purely as a short erm revenue grabber. WEll they wont catch me with that trick again

  9. The other problem that i am facing with FM is the lack of commercial components (usually, 3rd party components). As long as i don’t have the ability, for example, to export a grid to excel, I cannot use the new envitonment. Same goes for grouping and filtering and other standard commercial application activities that i excpect the component to have.

    Julian Bucknall (DevExpress) said (Oct 17 2011):
    “FireMonkey support is and always has been a long term proposal. There is no way I could prognosticate if and when we’ll be selling it. If you look at our VCL support, you’ll understand why it’s not a simple conversion.”

    I have a feeling that we will stick to VCL.

    • We’re a month away from making the decisions for the 2012 roadmap. From what we’ve seen of FireMonkey so far (and Chris’ post just reinforces our perceptions), I’m guessing we’ll be doing a lot more VCL enhancements over the next 12 months.

      Cheers, Julian

  10. Pingback: Delphi XE2 FireMonkey: great idea, but is it usable? « Tim Anderson’s ITWriting

  11. Perhaps an updated review for XE4 could be nice?
    Though i suspect we all already know the answer…
    FM is still junk… right?

Leave a Reply to David Rosen Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s