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….

- 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.

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….

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.

>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.

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.