- Front Panel: Connector pane terminals default to Required: CHECKED - I really love this option, which was added in LabVIEW 8.5. There were so many times in the past when I was working on an app, and I'd add inputs to a subVI but forget to wire them up in the calling VI, then spend several minutes debugging before I figured out what I'd done. Also, this option is smart enough to ignore error input terminals, leaving them as Recommended.
- Block Diagram: Enable automatic error handling in new VIs: UNCHECKED - I understand that this option exists for the benefit of new LabVIEW users, but for the rest of us, it's just WRONG.
- Block Diagram: Enable automatic wire routing: UNCHECKED - I've tried this option a few times, but I think my manual routing of wires produces much cleaner diagrams.
- Block Diagram: Enable auto wiring: CHECKED - I remember when I worked in the AE department and hadn't yet joined LabVIEW R&D, I attended a "demo day" on the LabVIEW floor where all the LabVIEW developers were showing off the features they were working on. When I saw this one (called "wire kissing" at the time), I thought it was way cool. And I've been a fan ever since, especially for automatically wiring error clusters. Note that when you drop objects with Super Quick Drop, auto wiring does not occur...but it's a small price to pay in order to be able to code at lightning speed...
- Front Panel/Block Diagram: Labels snap to preset positions on terminals: CHECKED - Another one of my favorites...this one was under my radar until it just appeared one day in a build of LabVIEW 8.0. My boss is a bigtime pixel-counter, so it was nice to have a really quick way to drag a label into the correct spot.
- Block Diagram: Place front panel terminals as icons: UNCHECKED - In LabVIEW R&D there is one extremely fierce advocate of keeping this feature checked by default. He shall remain nameless. If he wasn't around, though, we probably would have changed this option long ago (I'd personally prefer that we just remove it altogether). Looking at the big picture, though, it's probably worth having this option checked by default and keeping this guy around. :)
- Block Diagram: Place structures with Auto Grow enabled: UNCHECKED - I take pride in the way my diagrams look, and I like having 100% control over how they look. The thought of dropping a function in a nested structure, and having a bunch of crap all over the diagram move around as a result...it's a little too much for me to take.
- Block Diagram: Show red Xs on broken wires: UNCHECKED - Originally this feature did not have an entry in Tools > Options...you either lived with it, or found out what the INI token was to disable it. I hated the feature so much, I demanded a Tools > Options checkbox. What I didn't know was that, at the time (LabVIEW 7.0), the Block Diagram page in Tools > Options was completely full, and required a complete reorganization to fit in this new option. You should have seen the sad look on the unnamed developer's face (yes, the same one who likes terminal icons) when he realized that he was going to have to add my option. For those of you who hate red Xs, you're welcome.
- Block Diagram: Show dots at wire junctions: UNCHECKED - I just think they're ugly.
- Block Diagram: Show constant folding of wires/structures: UNCHECKED - The fuzzy wires make my eyes hurt. And I never really saw any benefit to knowing when constant folding is taking place. Seemed like more of a novelty than a utility.
- Block Diagram: Auto-insert Feedback Node in cycles: UNCHECKED - Don't get me wrong, I really like Feedback Nodes as a replacement for Functional Globals. But every once in a while I'd be wiring up some stuff in a loop, and connecting wires to each other while re-wiring things, and somehow my broken wires would turn into Feedback Nodes, and that freaked me out. So now I only get Feedback Nodes if I explicitly drop them myself.
- Alignment Grid: Everything: UNCHECKED - I don't like the grid. It makes things look too noisy.
- Controls/Functions Palettes: Palette Loading: LOAD PALETTES DURING LAUNCH - As you hopefully know by now, this enables Quick Drop to be instantly usable on its first use, at the expense of a slightly longer LabVIEW launch time.
- Environment: Maximum undo steps per VI: 99 - I've never seen any performance problems with cranking up this setting.
- Environment: Skip Getting Started window on launch: CHECKED - Since my LabVIEW launch time is a little longer for Quick Drop, I figure I can save a second or so if I don't have to load the GSW...I never really used it for anything special that I couldn't access from a new VI's File menu.
- Environment: Lock automatic tool selection: UNCHECKED - I'm a big fan of the Auto Tool, but I do like being able to press Tab, like the good ol' days, if I really need to.
Tuesday, February 24, 2009
My Tools > Options Settings
I've seen many people (myself included) make vocal arguments in favor of their own personal Tools > Options settings. Ultimately though, most of these settings come down to personal taste. Here now, are my personal preferences regarding many frequently-discussed Tools > Options settings, along with an occasional anecdote. Keep in mind that you can simply copy your LabVIEW.ini file from one LabVIEW installation to another to preserve these settings (so you don't have to go through and check/uncheck a bunch of options with every new LabVIEW install):
Subscribe to:
Post Comments (Atom)
Nice list.
ReplyDeleteQUOTE:
Block Diagram: Show red Xs on broken wires: UNCHECKED - Originally this feature did not have an entry in Tools > Options...you either lived with it, or found out what the INI token was to disable it. I hated the feature so much, I demanded a Tools > Options checkbox. ...For those of you who hate red Xs, you're welcome.
Thank you for removing those ugly items! (as well as the terminal icons).
As a developer I don't mind tuning my station in the initial 10 minutes I am at a fresh LabVIEW, so making the default values apply to beginner users is no a shame!
Could you tell us where the channel is to demand extra settings?
For over 2 years I am filing a bug report on the options dialog for SCC:
'The SCC options dialog is missing the option to exclude user.lib folders'
Everytime it is rejected as not a bug and a feature request is raised.
This is really (serious) something I have to work around in a daily basis. Either I miss the oppertunity to include whole trees into SCC at once, OR I have to disable every c:\program fil... item in the dependencies check in.
So if this feature finally made a LabVIEW versions my day would be good.
Ton
hey Darren. I'm in agreement on most of these except the following:
ReplyDeleteEnvironment: Lock automatic tool selection: CHECKED, I find I use the auto-tool more than not. If you want it off just Shift-right-click and click-off the autotool. Then just hit the tab button to re-enable it.
Block Diagram: Show dots at wire junctions: CHECKED - They are not ugly to me and actually serve a very useful purpose to define wire connections or overlaps.
Ton: The Product Suggestion Center (http://digital.ni.com/applications/psc.nsf/default?OpenForm ) is still the primary mechanism we have of receiving feedback from customers on new features, but we're investigating ways to get more interactive feedback from users in the future.
ReplyDeleteMike: When I switch away from the Auto Tool, I Tab. When I switch back to it, I Shift-Tab. Seems about as fast as your method.
No alignment grid and no dots... I'm noticing a pattern (no pun).
ReplyDeleteAutomatic error handling in new VIs helps catch missing error cluster wires between subVIs, right? I was thinking you only see a dialog if you've left out an error wire (which is helpful for beginners and nuggeteers). Am I missing something here?
Is there a secret INI token for permanently pinning loop conditional and iteration terminals to their original positions. When I say "pin", I mean have the terminals behave the way they do before you wire to them.
-Jason
Jason: Auto error handling pops up error dialogs. These error dialogs aren't coded by the programmer...as a general rule, intermediate and advanced LabVIEW programmers should have full control over the error handling in their programs, and probably don't want shipping code popping up error dialogs that they weren't expecting.
ReplyDeleteI don't know of any INI tokens related to loop iteration and conditional terminals. And don't they behave the opposite of how you're describing? If they're not wired, they'll move around as you resize the structure, but if they're wired to something, they'll stay in the same location when the structure is resized. Am I missing something?
...and one more thing. There are plenty of times when I don't wire the error output of a function simply because I don't really care if it errors (Close Reference comes to mind). In these cases, I *really* don't want an error dialog popping up when one of these nodes generates an error. I know some people will often wire the error output of a function in this case to a dummy sequence structure frame, or some equally no-op object. I don't agree with this approach...why make the code ugly when you should have just turned off Auto Error Handling in the first place?
ReplyDeleteHey D-
ReplyDeleteI meant pinned to the loop border as you described, not pinned to the current postion. It would be sweet to shrink / expand a loop and not have to drag the terminals around (ref. LabVIEW Proverb #154). :)
In our code, we wire all error clusters... When unexpected errors occur, rather than burying them by disabling "Auto Error Handling", we write the errors to an error.log. This way, the customer is not bothered by dialogs, but if they comment on strange behavior, they can view / send us the log.
If an error is expected, I'll clear that specific code and in some cases terminate the error cluster into a small sequence. That said, your point is valid; a VI with a small icon might be more asthetic.
-Jason
If your desire is that the customer "not [be] bothered by dialogs", then why do you have auto error handling enabled? Seems like your error logging mechanism is sophisticated enough that you don't need LabVIEW popping up unexpected error dialogs for you.
ReplyDeleteD-
ReplyDeleteI appreciate our discussion...
Our logging mechanism works well when all the error clusters are wired. The question here is what to do when the error chain is broken. That is, if the developer makes a mistake, do we want the customer to get a dialog.
I tend to lean "yes" on this since remote, intermittent problems can be difficult to debug WITH adequate information. How much more so if the dialogs are buried?
I'm currently dealing with something similar with the development environment where I am programmatically deploying LVLIBs via invoke node. Under certain conditions LabVIEW spontaneously closes when the method runs. I was able to call NI support, have them reproduce the problem, generate the necessary reports, and R&D is "looking into it". There were no helpful dialogs. Here we could generate some documentation, but in my case, if the error wire is left open, I have nothing without a dialog.
I know it's not elegant to display a dialog to the customer, but we would consider an unwired error cluster an internal mistake, and update their code (after addressing the cause of the dialog).
I don't intend to convince you here -- just provide a case where the dialogs may be helpful. If we always used error clusters and handled errors, then this would be a moot point.
-Jason
I thought it was amusing that I seem to have the same preferences for the options as you with the exception of the auto error handling. I know there are raging debates about this, but I am with Jason on the error handling. I handle every error explicitly, and yes, that does mean that occasionally I wire an error cluster to a frame or something, but at least I can look at it later and know that I didn't just forget. Often I'll use the error to warning to prevent a known (but irrelevant) error from being logged. The only time this choice is really frustrating for me is when I am looking at someone else's code who didn't handle errors properly.
ReplyDeleteChris
oh, and I forgot to mention that I'm almost positive that deployed code doesn't have any auto error handling dialogs, so the choice to enable the option is only relevant during development.
ReplyDeleteChris
Chris -- good point about looking at the code later and knowing you didn't forget to wire the error cluster.
ReplyDeleteIn your Build Specification (Application) Properties >> Source File Settings, if you select a VI and click "Customize VI Properties..", the last item is "Enable automatic error handling". By default this is set to "Use VI Property". So, if you're using AEH and not seeing dialogs, you've wired your error clusters properly.
-Jason