We are still waiting for our XE2 licenses to be organised but in the meantime I have started playing around with the Free Trial Edition. I haven’t had much time to form much of an opinion as yet, but have already identified some oddities in the FireMonkey Form Designer, specifically in the area of clipboard support.

At first I thought the clipboard was completely broken in the FireMonkey designer.

If I created a new FireMonkey application and dropped a few controls on a form and then tried to copy/paste those controls I simply couldn’t. The Cut/Copy options on the Edit menu were disabled and the keyboard shortcuts didn’t work.

Cut/Copy Disabled

I immediately tried the same thing in the VCL form designer and found that everything was working as expected. What was going on?

Responses to a Google+ post on the issue varied from those who saw the same thing and those who had no problems, all using the same XE2 build but with a variety of VM solutions. Eventually these responses pointed me in the direction of the Structure View… sure enough, I could Cut/Copy if I first selected the item I wished to Cut/Copy in the Structure View directly. Having done that, the Form Designer itself then also became “enabled” for Cut/Copy operations.

Cut/Copy Enabled - Structure View

This then raised a quirk in behaviour in the FireMonkey designer “Paste” operation which probably should be resolved. To understand this quirk though, let us quickly remind ourselves how the VCL designer has always worked:

In the VCL designer if you copy a control and then paste it back into the form, the new instance becomes selected by default. This is A Good Thing – you almost certainly want to change some properties on the new, pasted instance. If you then paste more instances, the freshly pasted control is the “paste context”. More often than not this isn’t important – most VCL controls cannot act as containers for other controls, so if you paste a TButton and then paste another TButton, the designer cannot paste it into the selected TButton and so the new instance is pasted into the selected button’s container.

This can be easily seen in action:

  • Place a TPanel on a VCL form
  • Place a TButton in that panel
  • Select and copy the button
  • Paste the button

The new button instance is selected by default

  • Paste again

Another new button is pasted with the TPanel as it’s parent.

Pasting Buttons in the VCL Designer

When you try to paste into a control that cannot act as a container, the VCL designer try to find the nearest parent that can act as a container and pastes into that.

Now repeat the same steps in the FireMonkey designer:

  • Place a TPanel on a FireMonkey form
  • Place a TButton in that panel
  • Select and copy the button
  • Paste the button

(NOTE: In my case, in order to be able to “Paste” I had to first click away from the button, de-selecting it, then click it again in the Structure View to select it once more)

The new button instance is selected by default – exactly the same as the VCL designer but the parent of the new button is the original button, NOT the panel!

  • Paste again

Another new button is pasted but this time the previously pasted button is the parent.

Pasting Buttons - FireMonkey

Crucially this isn’t immediately apparent because the nature of “parenting” in FireMonkey is quite different from that in the VCL – a parent control does not “clip” it’s children (in the examples I have found so far – there may be exceptions). So visually there is nothing to tell you that the pasted buttons are parented by anything other than the panel – unless and until you move the “root” button, at which point the other “child” buttons will move also as their positions are relative to their parent, obviously.

This at first appears to be a bug, but I think it’s more accurate to say it’s an oversight. The behaviour (apart from the initial clipboard bug) is essentially the same as that of the VCL designer. The difference is that any FireMonkey control can be the parent of any other FireMonkey control, so the consequences of assuming the selected control as the “paste context” and default selection of any newly pasted control combine to create the potential for unintentional nesting.

Suggested Fix/Change in Behaviour

Given that the “Parent/Child” relationship in FireMonkey is so different, I think the “Parent” property of any pasted control should respect and reflect the Parent property on the original Copy (or Cut) control. That is, if you paste a Control whose parent is “A” then it should be pasted with a parent of “A”. A “Shift” key modifier could be used to instruct the form designer to ignore the Parent property on the clipboard and instead paste into the currently selected control.

But in the meantime, this is something to be aware of when copy/pasting in the FireMonkey form designer.

13 thoughts on “XE2 FireMonkey Designer – Clipboard Gotcha

  1. FireMonkey has a long way to go. Try multiple select. Try the alignment toolbar. Look for the visual alignment lines that VCL has. Find the Anchor properties. Compare Margins and Padding between VCL and FMX. Try setting the tab order of a FMX form. Try setting the color of an edit box (hint: check EDN delphi.firemonkey forums for a how to). Figure out the difference between a TDateEdit and a TDateBox, a TComboEdit and a TComboBox.
    Lots and lots of little chimp droppings that make me go apeshit…

  2. Digging through the FMX source quickly shows bugs, and there is now a tempest brewing over code from GLScene (tho it may amount to nothing as the code pointed out so far is sufficently generic as it would not warrent copyright protection).

    I suspect that the issues related to the designer are based on the kuldging to get around the whole “firemonkey and vcl don’t go together” nonsense (the IDE is vcl after all).

    Clearly, Firemonkey is NOT ready for prime time yet. It was rushed out – we should all consider it more of a technology preview than anything.

    Sadly, the whole cross platform bit requires it…

  3. I think FMX is fine for a basic data input type application right now. It’s missing reporting, and it doesn’t look like TChart supports FMX styling yet (looks very out of place at this point IMO), but that will all change soon enough I’m sure. It’ll just take some time for third parties to get the hang of things is all. And I personally expected a significant SP1 for this release due to all the new technology introduced. Most of the things I’ve seen are very, very fixable in an SP.

  4. Jolyon, it might disagree with your VCL habits, but the copy-paste behavior is actually the correct one for a scene graph, which is what FireMonkey is.

    1. @Eric: I’m not sure that the “specification” of *any* “scene graph” goes so far as to define what copy/paste should do in a specific GUI editor for itself (the specification of the GUI will be a separate case from the specification of the scene graph).

      The fact that a particular graphics framework is implemented AS a scene graph says nothing about how the GUI’s that work within any particular domain specific implementation should work.

      That is the decision of the GUI designers and what is most appropriate to their use cases.

      The FireMonkey Form Designer is… a FORM DESIGNER. Not a “scene graph editor”, even though it may be technically precisely that.

      In a FORM designer, if I create a copy of a button contained by control X then I should get another button contained in control X – that is after all what “copy” means… make me another one LIKE THIS. The fact that the VCL achieves this result in most – but not all – cases is perhaps by accident rather than design.

      In the case of a “Cut” you could argue that the behaviour could/should be different but then you will get into a different kettle of fish with the behaviour of an action being determined by what action preceded it – i.e. paste does X if preceded by Copy but does Y if preceded by Cut. A variance which isn’t at all common w.r.t Cut/Copy/Paste behaviour… the difference between Cut/Copy is 99% expressed at the time of Cut/Copy, NOT at the time of Paste.

      Having said that, if *intuitive* such a variation shouldn’t matter – it would be interesting to explore that variation further perhaps.

      But no, I correct myself.

      It is absolutely positively by accident that the VCL get’s it right on the occasions that it does, as evidenced by the way that it also get’s it “wrong” when pasting controls that are containers. It is just that the consequences of that accident are writ far larger in the FireMonkey designer, exposed – but not excused – by it’s different fundamental architecture.

  5. Well, think of it other terms, and of breaking habits, what you’re asking would be a little bit like asking “why isn’t the primary Windows UI the keyboard and the DOS command line? Why using a mouse with only two buttons when my keyboard has 100+ keys?”

    >but then you will get into a different kettle of fish with the behaviour
    >of an action being determined by what action preceded it

    I don’t follow you there, you’re also asking for the action to be determined by the action that preceded it, you’re just arguing about how the preceding action should be interpreted. It’s rather common to have an action depend on what is currently selected, or what you were doing before.

    >the difference between Cut/Copy is 99% expressed at the time of
    >Cut/Copy, NOT at the time of Paste.

    Cut is traditionally expected to be a bundled copy+delete, that’s the only difference there should be between the two.

    In UI you often have things that should be together, and for which the alignment is relative (a label, its edit and a related button f.i.), in a graph you’ll nature parent those, and can then move them around as a group with relative positionning.

    That’s much more useful and productive than parenting to a parent container, and then having to manually keep thing together through multi-select and manual realigns, etc.

    1. I didn’t suggest preceding actions should modify following ones. I suggested that in the FireMonkey designer the “Parent” property should be preserved as part of a copy/paste operation.

      Always.

      (the only exception to this would of course be when the parent referenced on the clipboard no longer exists).

      I then also suggested that if the *user* wanted to paste into the form with the paste operation “rooted” at the currently selected object then a “Shift”+Paste operation could be used to achieve that.

  6. Yeah – there are some things that needs to be fixed…

    F12 Gotcha – after a FM application has run, you cannot switch from code to design by pressing F12.

    It is (oddly) possible to switch from design to code by pressing F12 after a run.

    After clicking tabs – F12 works again…

    Not really related to the Clipboard, but to the FM designer….

  7. Lets imagine a programmer that is creating his first FM application. He drops a panel on the form and then a button. After that he wants to place a button on the panel. He cuts out button, selects the panel and presses Ctrl+V. What happened? Button lands on the form, because form designer keeps parent. That programmer says a few nice words in the address of Jolyon Smith, and starts digging in the help. It takes him half an hour to find that magical Ctrl+Shift+V.
    Jolyon how mach time it took to fix your issue? I think much less then half an hour. So the current behaviour of the designer is actually better, don’t you think so?

    1. @Torbin – imagine the same developer who has put a button on a panel and then wants another button on the same panel. Well, he thinks – I already HAVE a button on that panel, so I shall simply copy that. So he copies the button he just placed, presses Ctrl+V and the new button is placed not as a child of the panel (i.e. the same parent as the original that was *copied*) but instead is placed as a child of the original button. Not only is the “Copy” NOT a copy (it has a different parent), but the thing being copied has also been changed (it now has a child)!!

      That’s some spooky quantum clipboard interaction going on right there! 🙂

      Actually, this isn’t possible with the bugs in the FireMonkey designer right now… you cannot Copy and then immediately Paste (on my XE2 installation – ymmv). You first have to change the selection in the structure view.

      It strikes me as much easier to explain to someone that if you copy a button which has it’s form as parent then you get *another* button with form as parent, than it is to explain that if you copy something then not everything about what you are copying actually gets… copied.

      Similarly it strikes me as very easy to explain that if you want to change the parent of something then you should do precisely that – change it’s parent. This functionality is a key feature of the Structure View! The use of Cut/Paste to re-parent controls I think pre-dates the Structure View, so the behaviour that made sense then, and which was coerced into behaving mostly intuitively mode by an accident of a property of the VCL, not by design, perhaps doesn’t make as much sense now.

      It’s somewhat ironic that I am told on the one hand I should unlearn my VCL designer habits AND ALSO be told that I should continue to maintain the habit of using a side-effect of the clipboard to re-assign parenting of controls…. 🙂

  8. …is essentially the same as that of the VCL designer. The difference is that any FireMonkey control can be the parent of any other FireMonkey control,

    – The GID is one aspect of the Firemonkey.

    The FireMonkey in the way we see it now is a very young evolution … and introduced during the time none one is allowed to talk about officially. So I think best is to report such things and give the team the opportunity to rethink and redesign. Anyway it is amazing that the such a fundamental change has been introduced in such a short period of time but already works ‘good’. Anyway an update package is said to come app. eom.

Comments are closed.