FMX in XE3 – good things and bad things

An easy way to summarise the good things about FMX in XE3 is to say it is much better than FMX in XE2; an easy way to summarise the bad things is to say it couldn’t have been any worse. Put another way, the promised regular XE2 updates for FMX turned out to be (a) less then regular, particularly after the first couple and (b) disappointingly slight; even so, browsing the source suggests a big reason for this was that the XE2 code was forked early on, with anyone competent devoting their time on the fork rather than the original.

Speaking in more specific terms, here’s some good things I’ve found about FMX in XE3:

  • The default Windows Vista/7 styling is pretty good, indeed good enough in my view. It’s at the level of custom drawn VCL controls (e.g. TSpeedButton) that try to look and behave ‘native’.
  • The awful walking-up-the-list thing I blogged about a few months ago has been largely fixed.
  • Actions are in.
  • Less a big deal than actions (at least for me), but anchors and a subset of the VCL’s touch and gesture support are in too.
  • TTabControl (equivalent to TPageControl in the VCL) actually works at design time. This is important if you are as tab-dependant like me…
  • It is possible to target OS X without a ‘main form’ concept being in effect, which is crucial to implement the basics of the Mac ‘document model’ (what I sometimes call myself ‘Mac-style MDI’).
  • The inherent flexibility of designing a UI using FMX compared to the VCL is still there.
  • The refactoring done for XE3 was largely for the better.

Nonetheless, even on its own terms, ‘FM2’ really needed a few more months. The bad things I’ve found include the following:

  • The menu code (crucial on OS X especially given the Mac menu bar) remains atrocious, being essentially the same as in XE2 –
    • Change a menu item’s state, and the whole menu bar is rebuilt (or would be – bugs and oversights mean nothing happens half the time).
    • TMainMenu is tied to a particular form, which doesn’t make sense on OS X.
    • Far more code than is actually necessary to do it right is used. I am inclined to say the person who wrote it is incompetent, though whoever authorised its inclusion and then failed to prioritise its fixing is just as bad.
  • Dancing text on Windows remains. This is a showstopper. What more can be said?
  • Too many properties and methods can return nil instead of raising an exception. A prime example of this is the Children property of TFmxObject when the object has no children. In that particular case, the cause is the internal FChildren list being nil until the first child is added, then freed and nil’ed when the final child is removed. This coding style is used elsewhere too, and I can only understand it as a ‘cargo cult’ practice picked up from reading the VCL source. In 2012 this only complicates the code unnecessarily however – truly, just create the list in the parent object’s constructor, and free it in the parent object’s destructor.
  • Still on the Children property, this directly exposes the internal list object. This is an error, because it allows client code to call SomeControl.Children.Add(NewChild) and therefore bypass the (virtual) AddObject method that remains the ‘proper’ way to add a child. Same with Delete/Remove and RemoveChild. (Before any says ‘but that’s just one property’ – TFmxObject is, as its name implies, a core class in the framework. Write it sloppily, and doubt arises about the quality of the framework generally.)
  • While the OS X side (well, most of it – see the next point) doesn’t enforce a ‘main form’ concept, the Windows side does. This is nothing to do with ‘native Windows behaviour’, but an ancient VCL-ism.
  • The small set of standard actions provided are unusable on OS X because they require a ‘main form’ to exist. They also have odd inefficiencies built into them.
  • The action code generally is over-fussy in my view, erroneously copying complications from the VCL code. I’m intending to blog about this separately.
  • Talking about actions, if you assign an action from a data module to a control, the IDE will sliently lose the association at a later point, just like in the VCL. Urgh!
  • I’m not sure about aspects of the default OS X styles. This isn’t necessarily EMBT’s fault – e.g., the ‘native’ equivalent of TTabControl is probably NSTabView, however NSTabView (a) puts has its ‘tabs’ centred not left-aligned and (b) isn’t actually used much by ‘native’ OS X applications. As it stands, the default OS X style for TTabControl takes its colours from NSTabView, but just looks weird because the sizing and positioning is different. Imitating the tab control styling in Safari or Firefox might be a better idea.
  • Efficient string interop on OS X appears to have been sacrificed in favour of cross compiling the FMX source using the upcoming ‘next generation compiler’ for iOS. To be clear, in your own code efficient string interop is still possible (both Delphi and Cocoa use UTF-16 internally) – it’s just that the FMX source deliberately uses clunky UTF-16 -> UTF-8 -> UTF-16 roundtrips via a ‘marshaller’.

My thoughts overall? If XE3 marked the first release of FMX, I would be very positive, notwithstanding the fact my list of ‘bad things’ is longer than the list of ‘good things’. In the case of the menu and action issues, for example, it is possible to work around them with a combination of interposer classes and custom IFMXxxxService implementations (for details, see this unit of mine). However, the happenings of a year ago are not just ‘water under the bridge’, and moreover, the fact FMX hasn’t been dogfooded even for the Platform Assistant installer (Java is still used instead!) doesn’t inspire confidence. The worry, quite simply, is that what remains to be fixed beyond straightforward bugs will now never be fixed.

Advertisements

33 thoughts on “FMX in XE3 – good things and bad things

  1. The quality of XE.. Delphi are just garbage. We bough XE2 to implement 64 DLL to integrate with MS Remote Deskop but found too many bug. Crash the host for no reason. Wait until they use their technology in their own product before you commit to use it for your app. We stick at Delphi 7 and 2007

    • For me, each Embarcadero release improved on its predecessor up until XE2. Sticking with D2007 if you’ve actually bought XE2 (and so can/could get an XE licence for ‘free’ if need be) is short-sighted IMO.

  2. Lack of fix for the dancing text is completely mind boggling.

    Memo and ListBox also have massive performance issues.

    Didn’t test the rest, the above two points are enough to still make FMX essentially irrelevant.

      • I’m a heavy VCL user and I’m still on Delphi XE (not interested in FMX). I haven’t upgraded to XE2 or XE3 because I’m worried that the quality of the VCL might have gone down (w/ the focus on FMX and x64). You mentioned TListBox is worse (I’m assuming you mean in the VCL since you say it got worse in XE2). Would you say that the number of bugs introduced in the VCL is greater or lesser than the number of bugs fixed in the VCL since XE?

        • Sorry, you misread – this is purely a discussion about FMX. Eric noted TListBox has significant issues in XE3, and I replied saying that at least it is better than in XE2.

          WRT the VCL, the biggest difference is the addition of (buggy) styling support in XE2, though if you avoid it, the effect is just to fatten up EXE sizes once again. Certain types have also been moved to new cross framework (VCL/FMX) units and aliases added to the VCL units, but apart from that, there hasn’t been enough work done on the VCL to make it particularly better or worse as such.

          If you need to produce x64 binaries you shouldn’t fear anything and so should upgrade straight away (aside from the VCL, COM stuff cross compiles fine too), but conversely, if you don’t need 64 bit, there’s no obvious reason to move beyond XE. In the case of the XE2 skinning support, for example, even Embarcadero themselves don’t use it – HTML5 Builder has just been released, and despite this being a VCL application that Embarcadero felt the need to use a custom theme for, it uses a third party party skinning solution!

  3. The installer used for the Platform Assistant is AFAIK InstallAnywhere, which is a good xplat installer that has proper support to deploy (and uninstall…) on each platform. Writing their own installer in FM would have been silly – unless one day InnoSetup is ported to FM (hope it isn’t, anyway…)

    • Er, the PAServer installer is crap and has never worked for me since I upgraded my Snow Leopard Mac to Lion – I have to find the actual files amongst umpteen nested directories in the .app bundle and extract them directly. The punchline is that this implies it doesn’t even need a custom installer! YMMV of course.

      • The lastest version of InstallAnywjere should support OSX 10.7 – I wonder if it’s an InstallAnywhere issue or Embarcadero is using an older version which doesn’t support 10.7 (which is fairly recent)

    • Have you tried this with the final version of XE2? I’ve just gone through your exact steps in XE2 update 4, hotfix 1, and can’t repeat the problem (OS X 10.7.4).

  4. One of the most frustrating part is the use local properties for “Global” attributes I’ve been doing some enhancements to the TGrid (after you work around the bugs) there are still issues where a single edit area will think it’s focused be cause it looks at a local boolean – Yuck

  5. I doubt it is reasonable to struggle against SomeControl.Children.Remove(xxx). Protect it however you can, but there is still xxx.Free; The answer for runtime is subclassing of list that is would ask the owner if this children is valid or not. And for coding time – use AddObject for your benefit of statical type check, or don’t – that does not harm FMX the library

    • Free’s fine, or should be (if you free a child control in the VCL, there won’t arise an orphaned reference in the parent). I don’t follow your point about AddObject, sorry.

      • Those are different concepts. Either we can add/remove items only via container specialized API, or we can do it via generic API. In GC-based or ref-counting languages there is no Obj.Free. You only can remove object from container via container methods. And you can make each container having its particular incompatible API for adding/removing items. Not for Delphi though. You cannot stop me from deleting the item outside the container API. Hence you cannot make hermetic isolated container API. Hence you should expose generic common uniform collection API like aforementioned .Children and make its implementation correctly matching generic API and specifics of the parent control. With Delphi you cannot force me to use non-compatible custom API for every object – then deal with fact that using pervasive TList API would be more uniform and easy for most develoeprs and make that TList API work coherently with all AddObject and all the rest auxillary ad hoc methods you want to add.

      • I did … if memory serves me right, I found problems that I attributed to bugs in every visual component I tested except TButton, TLabel and TEdit. FMX in XE2 was not worth the effort. It was supposed to be “Rapid Application Development” Studio XE2 after all. In the end, FMX1 was still anything but a RAD framework. Sadly, FMX2 is even worse in some areas: e.g. TPath.

        • “Sadly, FMX2 is even worse in some areas: e.g. TPath.”

          Another one is how certain aspects of the RTL when targeting OS X have been crappified internally, presumably so that the source can be compiled with the new iOS thing… I hope the developers making these decisions realise performant strings, easy native API interop, and the ability to engage in C-style programming (if you want to) are three key reasons for using (or still using) Delphi.

    • I’m currently researching for an FMX book, though I’m not sure what level it will be pitched at. What sort of topics do you have in mind?

Leave a 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s