Can I disable the Clean Up Diagram feature?

[xtal]

I've looked around but it appears I can't turn off/hide/diasable the Clean Up Diagram button in my LabVIEW environment.

Why I want to do this is a huge rant, so ignore the rest of this post if you don't want to hear anything negative on a lovely Friday.

As many of you know, I am the mentor of a FIRST Robotics team and we went to the World Championship last week. The programmer for our team, Tomas, learned all his LabVIEW from me, so he codes exactly like I do. I'm an old-school LabVIEW developer from long before there was an Undo and I've developed many habits and a particular style over the years. I don't think any of my style points are terribly wrong or bad; heck, I even helped develop and maintain the LabVIEW Style Guide used internally when I was on the LV development team. I like to have minimal wire bends, I like similar items aligned and distributed, I line items up by either the Error terminals or by like refnums. Structures are similar sizes and at most my diagrams need only be scrolled in one direction. I don't hide wires or nodes behind each other or shrink structures to hide things nor do I make structures larger than they need to be.

At the competition, we had some technical difficulties and in the spirit of coopertition, the programmers from other teams came by to help. It was all well and good until one kid hit the Clean Up Diagram and immediately saved the code. I've never see such a mess of technicolor spaghetti in my life! Tomas can no longer read his own code, so he can't make the changes to the program for our last matchs. I can't read his code, we are both frustrated ... and then it gets WORSE! We found a quiet place and try to fix the mess. Except that after every 3-4 edits like wire moves, structure resizes, etc, LabVIEW crashes with drawmgr.c messages. It was the most horrible LabVIEW experience I've ever had. I NEVER say anything bad about LabVIEW; I've even defended the poor misunderstood Express VIs...I'm still trying to make Shared Variables work...I will only program in LabVIEW. But I have nothing good to say about this "Clean Up Diagram" feature. I will never use it and I don't want it available on any LV development system I have to touch. I want to punch someone in the face for making a feature that makes kids cry and vow never to use LabVIEW again. {Okay, Tomas didn't actually cry, but I've never seen him so upset and he doesn't want to use LabVIEW ever again.} I now understand why that "I Hate LabVIEW" site exists. I'm almost ready to join it.

This has been bugging me for a week now and I'm glad I finally got to vent. For those who read this far, thanks for listening.

[Val Brown]

How about using Source Code Control and reverting to a version just prior to that "helpful" input?

I may be misunderstanding here but this seems to me to be a primary example of the value of backing up and/or SCC. I use Subversion now and have found it to be useful -- FWIW.

[gleichman]

I can't answer your question other than the obvious, "Make a backup before letting someone touch your code."

This is my first year mentoring an FRC team and my two senior programmers love diagram cleanup, so I hope it wasn't one them. It's been an interesting challenge for me to encourage good programming style without being annoying.

[PaulL]

Sorry to hear about the horrible experience Tomas and you had! Sounds awful!

I have to say, though, that I use the diagram clean-up tool all the time (it works well for the type of VIs I write--but it would not be good for other types of VIs, to be sure) and I have never seen it cause a drawmgr.cpp error.

I totally agree it should be possible to turn off the feature, since not all users like it and it is not well-suited to some design approaches. For some design approaches, though, it works quite well!

Good luck with the FRC in the future!

[crelf]

I'm not going to argue the merits and pitfalls of the Cleanup Block Diagram feature, but I don't think disabling it makes sense. I mean, it's like any other part of the LabVIEW development environment - and it's terribly unfortunate that someone did a BDC and then saved the VI, but that's a two step process driven by the user - I don't think that the development environment should have to handle that use case. You could as easily say that you don't want to be able to save VIs that have had the BDC used on them

[jdunham]

Agreed on the SCC option. That other kid could have done any number of things (deletions, etc.) and saved the code, and whether or not it was intentional doesn't matter too much; it's still a risk. I use SVN too, though Mercurial seems like a better fit for this situation since all the change history for the current branch should be available even if you are disconnected from the internet. You could do that with SVN too if you run a local server.

I'm sorry for the awful situation, but I don't know that disabling a toolbar button is the real answer.

[xtal]

I'm sorry for the awful situation, but I don't know that disabling a toolbar button is the real answer.

We can disable/hide the Abort button and turn off debugging. I don't see why it's an unreasonable request.

For those who are suggesting SCC, you are completely missing the point. The drive computer is a bare-bones system that communicates with the robot during a competition. It's not the development machine/environment. We only change the code between matches based on how the robot performs. We use SolidWorks to model and design the robot, too, but we certainly can't put it on the drive computer, either.

[Val Brown]

A flash drive backup would seem to be an alternative as well in that case.

[xtal]

A flash drive backup would seem to be an alternative as well in that case.

We did after it was all "fixed" but we were heavily in trouble-shooting mode at the time and all available USB drives were occupied with ESTOP, joysticks, and such. We had no idea the kid was gonna modify our code like that. I wasn't even there since there wasn't room in the pit and I needed to talk to the NI folks about some cRIO things. It would be so much easier if I could just disable that button like I can the Abort and Continuous Run ones. Why is that so unreasonable?

[Val Brown]

I guess for me it's kind of like asking to have the ability to have something like the CTL-A>Delete option disabled in case someone malicious comes around and does that, then saves your VI. Disabling Abort and Continuous Run seem different to me, FWIW, in that they can be part of a built application, whereas BDC can't be -- its only in the IDE.

[crelf]

We can disable/hide the Abort button and turn off debugging. I don't see why it's an unreasonable request.

I see what you mean, but they're run-time settings, the BDC is an edit time thing. I'm not saying it's an unreasonable request, but saying that you want to be able to disbale BDC is like saying that you want to disable undo or align right - where does it stop?

I think the request might be better phrased as: Wouldn't it be great to be able to undo anything, even after a VI is saved?

We had no idea the kid was gonna modify our code like that... It would be so much easier if I could just disable that button like I can the Abort and Continuous Run ones.

Sounds like you should temporarily disable that kid

[Dan DeFriese]

I see what you mean, but they're run-time settings, the BDC is an edit time thing. I'm not saying it's an unreasonable request, but saying that you want to be able to disbale BDC is like saying that you want to disable undo or align right - where does it stop?

Why should we have to stop? I don't know about "disabling" a feature (except that damn conflict dialog), but being able to configure which toolbar buttons are visible seems very reasonable to me. MS Office has provided this capability since as long as I can remember.

I don't care for the BD Clean-up either so I deleted the CTRL + U menu shortcut in the options to prevent inadvertant use on my system.

[crelf]

Why should we have to stop? I don't know about "disabling" a feature (except that damn conflict dialog), but being able to configure which toolbar buttons are visible seems very reasonable to me. MS Office has provided this capability since as long as I can remember.

Now that's a different question - or maybe the same question, but with a different motivation: I agree that we could have more control of the IDE, but we should think carefully about what we want before putting that in front of NI.

[Val Brown]

...and whether or not that programming effort would be better spent on other features, overall stability, etc.

[jdunham]

For those who are suggesting SCC, you are completely missing the point. The drive computer is a bare-bones system that communicates with the robot during a competition. It's not the development machine/environment. We only change the code between matches based on how the robot performs. We use SolidWorks to model and design the robot, too, but we certainly can't put it on the drive computer, either.

Brining this back off-topic again, I think Mercurial is pretty lightweight and you could run it from a USB drive or by temporarily dropping a few files on the hard drive of the competition computer. It seems like that ability to back out changes or restore a configuration from a previous robomatch would really be a lifesaver in this environment.

[Michael Aivaliotis]

I think allowing undo after save would have helped here. There's already an idea exchange post on it. And it looks like it's in Beta so we might see it in the next release? Who knows.

But I am on board with you Crystal. I can feel your pain. I've been in that situation before. I also agree that the diagram cleanup is bad. I would go over here and do some yelling.

I have not tried it but I heard Mercurial, another SCC program actually allows you to have a localized repository so you could have gotten out of that situation perhaps.

[Val Brown]

SVN will allow a local repo as well.

[Darren]

It seems to me that diagram cleanup is the scapegoat in this situation (why isn't it the evil kid who pressed Ctrl-S on code that wasn't his?). The scapegoat could have just as easily been the Delete key, the Backspace key, a case structure wrapped around the code then removed with an empty case showing, etc. etc. Once Ctrl-S is pressed after any of these actions, you're screwed unless you (1) have a readily available backup of your code or (2) are able in a future LabVIEW version to undo after save. Since it's not August 2011 yet, I vote for the readily available backup of your code.

The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

[Val Brown]

And, um, Darren I'm glad to see that your comment means that some form of "undo after Save" is coming, hmmmm, sometime around NI Wekk 2001 I guess. Nice!

[crelf]

The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

+1

[Dan DeFriese]

The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

The Resolve Confict dialog(s) are forced upon me occasionally when I move stuff around intentionally. That feature upsets me so much I have to go get a cup of coffee after 1-10 minutes of arrow-enter . Can we vilify that feature?

[Darren]

The Resolve Confict dialog(s) are forced upon me occasionally when I move stuff around intentionally. That feature upsets me so much I have to go get a cup of coffee after 1-10 minutes of arrow-enter . Can we vilify that feature?

I too have been unable to resolve my conflict with the Resolve Conflicts dialog. So yes, vilify away.

[xtal]

The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

I vilify Clean Up Diagram because it deserves it. How do you "improperly use" a button? There was nothing even remotely "clean" in what it produced; I can't imagine ANY LV programmer wanting their code to look like that. If someone hit Delete, then the *situation* would suck because that's what Delete is supposed to do and you might have clicked it when you didn't mean to. As it stands, I think the Cleanup feature sucks because it doesn't do what it is supposed to.

[jdunham]

How about whenever you move more than two nodes wire segments without adding or deleting anything, a little animated broom comes up and says "It looks like you're trying to clean up your diagram..." Or maybe it could be a paper clip; I know one who's out of work right now.

[Darren]

I vilify Clean Up Diagram because it deserves it. How do you "improperly use" a button? There was nothing even remotely "clean" in what it produced; I can't imagine ANY LV programmer wanting their code to look like that. If someone hit Delete, then the *situation* would suck because that's what Delete is supposed to do and you might have clicked it when you didn't mean to. As it stands, I think the Cleanup feature sucks because it doesn't do what it is supposed to.

(LAVA ate my previous post, and I don't quite remember all of what I said...here's the short version)

Diagram Cleanup does what it's supposed to do on small, lightly-nested VIs, which should make up the bulk of the VIs in your application if it's sufficiently modular. On large and/or heavily-nested diagrams, it should not be used. Check out the whole story of my feelings on block diagram cleanup in this blog post.