Keep block diagram layout when copying between front panels and vice versa

[Mads]

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

Why not just keep both as they were when copying?

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

[JimChretz]

I totally agree, all the object properties should be maintained, all the wires attached should follow as well.

[AristosQueue (NI)]

We could do a better job spacing out the diagram terminals when panel gets copied, but overall, in both cases, fitting the controls/indicators into the existing panel seems important.

[AristosQueue (NI)]

Kicking the tires some more:

Currently, the thing being pasted (diag or panel) is assumed to be pasted by the user into a desirable position. But the other target (panel or diag) is not visible by the user at the time of pasting, so the element is "best fit" into the other target.

When copy/pasting a single control or a single terminal, this approach works well.

When copy/pasting a group of controls or a group of terminals, each individual piece of the "other target" gets best fit. We could instead try to best fit a space big enough for all the elements as a group, whatever their space requirements in the original copied code. So, for example, when copying a numeric terminal and a boolean terminal, instead of finding enough empty space for one numeric control and then enough empty space for one boolean, we would find a single block of empty space for the numeric and boolean in the relative positions they had on the original panel, then put the new copies into that single empty block.

That approach would seem to satisfy the idea request above and keep the pasted contents from sitting on top of the existing contents.

[Mads]

Trying to find space for the content as an unchanged block/single entity is the request yes.

In the example there *is* ample space to fit the copied bits unchanged to the target diagram, but as you indicate the algorithm still repositions the controls individually. Ironically the result then is lots of overlap, not (just) with (if any) existing code, but here also between the elements of the copied code.

[AristosQueue (NI)]

The overlap in the diagram is because the algorithm ignores the labels when finding space. That's been a controversial decision for years, but ignoring the labels gets things placed with better alignment in many cases. I don't know if that should change or not.

[gregopher]

since there are algorithmic reasons things are happening, perhaps there could be a optional holding area for the pasted objects on the other target so the user can drop them somewhere useful the next time they open that target.  The holding area could be to the left or right of any existing objects.

[crossrulz]

gregopher,

That would be this idea: Unused items tray 

[Mads]

The unused items tray would not necessarily fix the cluttering issue...

It existed in NXG...and frankly I for one did not like it. It hindered my usual work flow; I add or copy a control to a panel, place it where I want it, then double-click on a control/terminal to jump to the block diagram/front panel to continue my work.... I do not have NXG available right now, but as far as I remember double-clicking like that would not move you to the next diagram and show the unused item....It also hides the items too much. The way it works now the items might be seemingly randomly placed, but at least I can access them quickly through double-clicking their front(terminal counterpart and if I have forgotten them (very unlikely) I still discover them quickly enough....

You could perhaps improve the unused items visibility and accessibility enough to make it compete with the current solution. Some of the suggestions mentioned in the thread of the unsued item tray idea would be better (placing them automatically as picked up items once you switch panel, and/or jjust always put them at the border of the existing items.

[Mads]

Another thing that really should be kept when copying is the tabbing order(!).

If you have ordered the tabbing order of your controls, but then need to copy them to another panel - the tab order is changed. I am not just talking about changing it to fit among the tab order of existing panel items; the order within the copied is changed too. 

[wiebe@CARYA]

> the tab order is changed. 

It seems the tabbing order is set to the Z-Order of the items.

If you simply add some controls, the tabbing order will stay the same after a copy paste. To reproduce the problem, you have to change the tabbing order from the default, which is the Z-Order.

The tabbing order is a property of the panel, so it's inconvenient, but it makes some sense.