Labview 2016 new improvments to selecting, moving and resizing objects

[Craig_S.]

---

@aucman wrote:

Tnx. I tested it and for moving objects it is working great. Especially x key is great. I couldnt made it to work when holding CTRL key (copying). If anybody will have time to figure it out thanks in advanced.

---

Don't hold Ctrl down; start the drag with Ctrl pressed to initiate a copy-drag, then release it and press 'x' to toggle.

You can also start the drag without Ctrl pressed, toggle liveness with 'x', then press Ctrl to turn a normal drag into a copy-drag (but in this case you have to keep Ctrl down when you release the mouse, or it turns back into a normal non-copy drag).

[Ben]

Hi Craig,

I want to thank you for stepping in and helping us out! I also want to thank you and whoever was involved and implemented this features that you have revealed to us. Nice job!

It shows that someone tested it thoughly, found it lacking and included the option to avoid the complications when needed.

Megga-Kudos to you adn all!

Thank you!

Ben

[GregSands]

I'm so glad you posted these tips for handling live dragging. I was very close to downgrading again from 2016 because of not only the slowness of dragging (even in fairly small diagrams), but also it would often lose the drag altogether, especially when dragging or copying in to or out of multilayer structures. 

I understand the changes in 2016 are just the first stage in a whole new UI for LabVIEW - if it's anything to go by, then there's a lot more work to be done before rolling it out any further.

[Craig_S.]

---

@GregSands wrote:

I'm so glad you posted these tips for handling live dragging. I was very close to downgrading again from 2016 because of not only the slowness of dragging (even in fairly small diagrams), but also it would often lose the drag altogether, especially when dragging or copying in to or out of multilayer structures. 

I understand the changes in 2016 are just the first stage in a whole new UI for LabVIEW - if it's anything to go by, then there's a lot more work to be done before rolling it out any further.

---

What are the specs of your development machine?  Could you provide an example of a VI which has a fairly small diagram but has unacceptable dragging performance?  Generally feedback on the feature has been positive and sluggishness the exception, not the rule.  If any refresh during drag takes longer than 200 ms, the feature automatically turns off to try to mitigate unpleasantness.  I don't know what you mean by "losing the drag altogether", but if you could elaborate, that would be helpful.

(Does anyone else reading this agree or disagree with whether the live drag behavior is performant enough to be a net benefit?)

I should also note that the live drag in 2016 is not the same implementation as the one in the "whole new UI" for LabVIEW, so you can make no inferences about its future behavior or performance from 2016.

[GregSands]

Development machine specs are two brand-new Dell computers, one a laptop, one a workstation, both with Core i7 and 16GB and 64GB memory. I realise my definition of "fairly small" may not be that - it was a VI hierarchy with ~800 nodes and 50 structures in the main program, and ~3000 nodes overall - although it's small in relation to the main software I work on which is still currently in LV2012 and has several tens of thousands of nodes. 

Often when dragging between structures that have autogrow on, the "drag" would flash back and forth between the original and new location, and sometimes would just return to the original spot and no longer be attached to the cursor - that's what I mean by losing the drag altogether.  This has happened for normal drags, but more often when doing a drag/copy, and is also more common when the drag content is fairly large (10-20 items I guess).  On other occasions the drag works, but is extremely sluggish, certainly much more than 200ms, and no change is made to the drag behaviour.

I've just tried it with another similar but slightly smaller VI (400 nodes) - I can't really attach the VI itself, but here's a screenshot. 

If I grab a single node from the central structure (e.g. the "_InterpreterExit" string constant) and move or copy it with LiveDrag turned on, it will drag through a couple of case structure boundaries, and then it loses the drag and the string constant is selected but unmoving in its original position.  All structures have autogrow on, and most only have a couple of frames except the innermost with 20 or so.

Hope that's enough to give the idea.  For me, the live drag is not particularly useful and I'm quite happy with it now that it's turned off!  Hate to think though about the development time, especially if it's not going to be used in the future.

[RichardBallantyne]

In LabVIEW 2016, they added this "feature" which I really dislike:

"When you select objects, the area covered by the selection rectangle displays in gray and a marquee highlights the selected objects. Selected structures appear with a darker background to indicate your selection includes them."

Am I the only developer who hates the new GREY dotted border that shows up around objects after the user selects them on the block diagram by clicking?  This light grey color is hard to see.  In all previous versions of LabVIEW, the selected objects had a very visible BLACK dotted outline, which was much better!  Is there a way to set the color of the highlighting border around selected block diagram objects?

[Hooovahh]

I've taken to turning off the live dragging features using the INI key.  I'm seeing various performance issues in 2016 in general, and interacting with the IDE is just one of the slownesses I'm seeing.  If disabling the live drag improves performance at all then that's what I want.  If there were an INI key to disable the selection rectangle I'd probably do that as well, even though I kinda like the feature, but it isn't worth the trade off of a sluggish IDE that I've been having.  In fact I think for my current project I'll be rolling it back to 2015.  Keep in mind my issues could be isolated to my project or something I'm doing, but whatever it is I don't like it.

[RichardBallantyne]

---

@Hooovahh wrote:

I'm seeing various performance issues in 2016 in general, and interacting with the IDE is just one of the slownesses I'm seeing.  If disabling the live drag improves performance at all then that's what I want.

---

I am seeing the same performance issues.  It is incredibly frustrating for me to use LabVIEW 2016.  I've been coding in LabVIEW for 20 years and LABVIEW 2016 is unbearably slow compared to previous versions.  Saving a large VI takes 10x longer.  Block diagram tasks are taking way longer than they should.  I can't switch back to 2015 because another developer in my group has already switched to 2016 and committed LabVIEW 2016 VI's to our SVN repository.  I will try disabling the live drag "feature" in the labview.ini file.  If that doesn't work, then maybe I'll just switch to C# since that is the direction our company is going with all new SW development.

[Hooovahh]

---

@RichardBallantyne wrote:

---

If that doesn't work, then maybe I'll just switch to C# since that is the direction our company is going with all new SW development.

Well I wouldn't be one to throw out the baby with the bath water, but it is an issue that I'm hoping NI is aware of for the next release.  SP1 would be a great time to add some stability and performance improvements.

[RichardBallantyne]

So the "LiveDrag=False" labview.ini option helped a lot, however, it still takes a long time to save large VIs to disk, whereas LabVIEW 2015 saving was instantaneous with the exact same VIs.  Also, I notice the same problem mentioned in this thread with the block diagrams automatically expanding (suddently poping bigger) sometimes when copying (via control-click-drag-unclick) an object on the block diagram.  This is very annoying as I like my block diagrams as compact and neat as possible.  I always have kept "Autogrow" disabled, but in LV2016 block diagrams sometimes grow anyway.