Leaderboard

For those that don't know if you double click a subVI while holding the CTRL key it will open the front panel and block diagram but bring up the block diagram. This also works when the VI is running (quite handy) but it only works if Auto-Tool is off when the VI is running. As for the topic I basically said my concern in the other thread that it may affect my skill as a programmer if I have less visual ques, between the software function and a visual representation of the software function. If this is compensated or improved with some other feature I'm all for it.

Created a separate topic to discuss about the need for FP. We can go back to discussing about 1px bends in here. http://lavag.org/topic/17326-should-bd-be-allowed-without-fp/

Because the FP can be very helpful when debugging, I wouldn't support getting rid of it altogether. However, VIs should have a property that hides the FP and only shows the block diagram (and show the connector pane on the BD screen as well). One major benefit of this would be to have only half the amount of windows opened when troubleshooting a deeply nested VI and getting to your point of interest faster than having to press "Ctrl-E" every time you open a VI. By allowing to hide FP and let a BD window open by itself, you could even have a feature that opens only the BD of a VI when the "Ctrl" key is down regardless of the VI's properties. Since the FP should stay, I still support Jack's original idea and Mark's tool to have a FP auto clean-up so that FP look clean when you need them while not t wasting time with them when you don't. Nowadays, unless you spend some time organising the controls on your FP, your programs can "look bad" even if you have the cleanest code on the BD which really is the only thing that matters. Regarding the notion of a VI being a "Virtual Instrument" and therefore requiring an interface, I think it's time to acknowledge that only a minority of VIs are actually visible to the users and to support the idea of the code be the most important part of the program instead the graphical representation of the function's I/Os which serves little purpose 95%+ of the time.

Icon View, Auto-Insert Feedback Node, Auto-Tool, Scripting. The default settings I change on each install of LabVIEW. I'm not saying my views on these features won't change, but I do think that it tells you something about what kind of LabVIEW programmer you are if you only ever use the icon view for terminals. I believe there was a CLAD question once that was something of "What are the main components of a subVI". Likely wanting you to say Block Diagram, Front Panel, but I agree that a VI doesn't really need a front panel. And if I choose to remove the block diagram I guess my VI doesn't really need that either. But at some point I feel like we may lose something. LabVIEW is visual (duh) and as a result I feel like my brain makes connections between the subVI icon and the functions it performs. This helps me remember things very quickly and traversing down the rabbit hole of subVIs seems easy because i remember all their functions visually. Likewise my brain makes connections between the front panel and block diagram and knows how controls on the front panel and indicators are coupled. I started this post wanted to say I was on board with removing the front panel, but now I'm not so sure, unless there is again some visual way for me to understand code in a way that is hard to explain. In text based code I find my self remembering what the code does, based on the shape of the text in that line (or surrounding lines). I feel like I'm a better programmer because of these visual connections, and I hope that if the Front Panel goes away, some new method will be there to replace the visual connection that will be lost.

Are you sure you meant to say "turn on icon view for terminals" and not to "turn off icon view for sub-vis"? I honestly cannot see any benefit to making the terminal take up more space. I do agree with your point of spreading things out and leaving room to grow if necessary in the future. But, I have seen benefit to turning off icon view for a sub-vi on occasion. Especially for situations where you cannot keep the con pane down to 4224. But now with LVOOP, that seems to be less of a problem. I do agree that accessors have no good reason to have FPs. For that matter, they really don't even need BDs. Maybe I am in the minority but I never edit 99.9% of the ones I auto-create and they mainly mess up my VI analyzer tests because the scripting that creates them does not deal well with long class names. (terminal labels tend to overlap the case structure) Seriously, icon view terminals? The next thing you will suggest is using Express VIs!

I'll take vomit any day over some of the code I've been lucky enough to deal with.

Okay this makes a little more sense. Typically when I design an application like this, I don't allow my VI in the subpanel to stop itself. I only have the parent VI (the one with the subpanel) insert/remove/or stop the VI. You obviously need some mechanism to tell the parent VI that the child VI has stopped if you are going to allow your child VI to stop running like this. There are many ways to do this, the easiest is probably a functional global with an array of references and an array of booleans or enums keeping track of the state of the dynamically loaded VIs. Then your parent VI can read this global data and know to insert a new VI or use the existing reference. Other things that could work are queues, notifiers, user events, and probably many others.

Once again I will suggest that the icon of the Always Copy node should be changed to a Band-Aid. A Roach Motel would also work, but that is probably harder to draw in such a small space.