Lock Block diagram object from accidental editing

[Omar_II]

Along the lines of this idea Enable-Diagram-or-Inverse-Disable-Diagram

I would like to be able to lock block diagram objects to prevent accidental editing.

We can turn on and off the menu button of Resource name constants to prevent accidental editing

I would like to be able to do that (lock) other block diagram objects. Mainly the objects that you click on and select its state from a drop down menu or click on and toggle between two states. Block diagram objects that can be edited accidentally when all you wanted to was to move it

Add Menu Button for enum block diagram Constance that we can turn on or off to prevent accidental editing.

Local variables

True/False (I like Altenbach idea for the true false Constance)

While Loops stop/continue

Property Nodes

etc

Or some way to lock the code but still be able to view it.

We share VI among coworkers and many times they accidentally chance something when they that wanted to see what was going on inside a sub VI to verify it works the way then think it works.

[JackDunaway]

The best way to "lock" code against the curious coworker is to use source code control. SCC allows any of us in the group to check out the entire project, completely trash it with experimental code, or as you say, to just get a feel for it, and then wax it and check out a clean project again.

[smercurio_fc]

I agree that SCC is by far the best solution for this.

Besides, you can already do what you want to do: Just lock the VI without a password. If all they're doing is looking at the block diagram, that will still allow them to do so, but not make changes.

Also, they should learn to not save a VI they shouldn't be making changes to. Of course, humans being what they are, if they do, SCC would allow you to easily recover.

[altenbach]

I can see some use for this.

Basically, you want to be able lock the current value of a diagram constant from accidental changes by the programmer.

At the same time a locked diagram constant can still be moved around, but a value change would need an unlock operation first.

Especially a new programmer unfamiliar with the autotool, might accidentally toggle a boolean constant when trying to move it. A locked constant would prevent this and could save a few hours of debugging. 😄

[smercurio_fc]

Good point about the Boolean constants. One of the few times that I prefer text-based languages. Much harder to make accidental changes.

[Broken_Arrow]

I like this. Not only for accidental changes (like a bool array), but to make myself think twice. A good example is a lookup table - a 2D array full of constants. If I try to edit it, the lock just reminds me "hey! those values are important, what are you doing?"

[RavensFan]

Subject:  Have Ability to Lock Constants on Block Diagram

At first, I was going to post this as a New Idea.   I did a search for" lock data in constant" and surprisingly, I found only one discussion of it in a thread that is 7 years old.  I don't know why this idea didn't pop up in that search (maybe is was that the original poster misspelled "constants").  Only after I did a search for "group block diagram" (thinking of a related idea to this one) did this Idea show up in the results.  I actually had seen this idea before and put in my Kudo, I just didn't remember it.

Since I already had the message mostly typed up and almost posted when I found this message, I am just going to add my commentary as a reply here rather than generate a duplicate idea.  I hope it gets some life again and more people will Kudo than the handful that have to date. 

Sometimes when doing some coding on the block diagram, mouse clicks can get kind of dangerous.

Suppose you have carefully created a constant of a 2-D array of booleans with a special pattern that means something for your application.  A misplaced mouse click can change a True to a False, or vice versa.  And it would be very easy not to detect that you did this and correct it.

Suppose you have an enum constant on the diagram.  A bad mouse click causes another item in the constant to be selected inadvertently.

Suppose you have an array.  The values have been carefully selected among different elements in the array.  You accidentally highlight the element and drag it out. If you're quick, you undo and everything is restored.  But if you don't see it, all your work in selecting values for that array are lost.  You are left if with an empty array container.  If you drag an element back in, you don't get your array back, but just an empty array of that datatype.  I accidentally drag stuff out quite often.  Fortunately, I see it right a way and am able to Undo the action.  But it is still a nuisance.  And the difference between selecting the array container or an element of the array is just a couple pixels.

We should have the ability to right click on a constant and lock the values.  If you need to edit them later, you can unlock it, edit, and lock again.  Perhaps a special glyph or some other visual appearance can indicate the object has locked values.

The old thread does suggest some work arounds such as changing a constant to a control and hiding it, a horrible idea.  Or wrapping up the constant in a subVI.  This would be a good idea in the long run, but if you are still actively working on and debugging the application, you may not be ready to hide the constant away just yet.

Message Edited by Ravens Fan on 01-23-2010 02:21 AM

[danny_t]

Hi,

I would really like this feature,the main thing I find is with Boolean constans, it is very easy when moving them around to accidently change the state of them.  Yes source control acts s a lock, but as I am most likly changing something on the block diagram anyway, I am expecting a new version to be generated by my editing.

OK, so I do a peer review of the code as well ,but things like a simple true becomes a false can be missed

[peterjim]

I agree about the unhelpful ease of modifying booleans - Boolean constants should be locked by default (after all, you did ask for a "constant" when you placed it!). A right-click menu choice should be required to change it (in effect, to replace it with a different constant) Because of this problem, some people employ work-arounds to avoid using boolean constants (like using the inside of the selector terminal in boolean case boxes in preference). These always more wire complexity, which is bad in my book. It would be good to fix it at the source of the problem.

[AristosQueue (NI)]

Have any of you looked at LabVIEW Web UI Builder? It's a new product that NI released in October specifically for creating front panels to display on web pages. It is not a part of LabVIEW -- it's a completely independent product and we reused the concepts from the LV block diagram as its programming interface. There are several ideas in that environment that we might try in LabVIEW itself in the future. One of those has to do with these stray clicks causing changes.

In Web UI Builder, a constant must be selected first and then you can click on it to modify its value. That approach solved two problems: it means less autotool confusion and it means you can't accidentally single click on something and change its value.

What would you think of this approach being used in LabVIEW in the future?

Video intro to Web UI Builder here.

Product info for Web UI Builder here.

[SteveChandler]

What about double clicking on the constant to enable editing? After double clicking there could be some kind of indication that it can be edited. Maybe the rest of the block diagram dims or something. Then if you change your mind just single click on the diagram to disable editing.

It is way different than current LabVIEW so it should of course be an ini option.