LabVIEW Pet Peeves

[hfettig]

I thought I'd start a topic about pet peeves with regards to the LabVIEW development environment.

Maybe it is just me being ignorant and somebody knows a way around these things.

Maybe you have some pet peeves too that you would like to share.

My number one pet peeve is the fact that when I create a new custom control, be that via File -> New -> Control and Advanced -> Customize, the default setting for this control is Control. However, 95% of the time I am creating typedefs, which means I have to change the setting to Typedef. It would be great if it would come up as Typedef by default. I would even settle for an LabView.ini setting where you can select the default.

Number two has to do with the Properties dialog for front panel controls. On the Appearance tab, why are the text boxes for Label and Caption grayed out when I uncheck visible? The text of either is in no way related to the visibility. So if I want to change the label, say after I have copied a bunch of controls, and the label is invisible, I first have to make it visible, change the label, and then make it invisible again. Now if that is not annoying enough, if the control happens to sit close to the inside edge of a tab control, making the label visible might resize the tab control, which is not undone by making the label invisible again.

The third one is has to do with the fact that you cannot select a bunch of similar controls and change properties for all of them at once. I know that might be difficult to implement but it would be highly useful. Many times I have a number of digital numeric controls on the frontpanel and want to make the Format & Precision the same. Currently I have to select one after another and change them separately. I did try to build a properties copy tool once but never could quite get to work.

Well that's all for now. If you have some suggestions or would like to share your own pet peeves, feel free to reply.

Cheers,

Heiko

[LAVA 1.0 Content]

QUOTE (hfettig @ Jul 25 2008, 09:01 AM)

I thought I'd start a topic about pet peeves with regards to the LabVIEW development environment.

Maybe it is just me being ignorant and somebody knows a way around these things.

Maybe you have some pet peeves too that you would like to share.

...

The third one is has to do with the fact that you cannot select a bunch of similar controls and change properties for all of them at once. I know that might be difficult to implement but it would be highly useful. Many times I have a number of digital numeric controls on the frontpanel and want to make the Format & Precision the same. Currently I have to select one after another and change them separately. I did try to build a properties copy tool once but never could quite get to work.

Well that's all for now. If you have some suggestions or would like to share your own pet peeves, feel free to reply.

Cheers,

Heiko

The "Resize Objects" is a great initial step toward that end goal. I am very pleased with that function!

I have a zillion pet-peeves but my top ones are;

The default palette style requires multiple steps to get at a "For Loop".

Auto-grow (auto-explode) option is true by default.

Ben

[hfettig]

QUOTE (neB @ Jul 25 2008, 09:12 AM)

Auto-grow (auto-explode) option is true by default.

Ah yes, Auto-Groan. Especially annoying when you have nested structures that all grow. And all just because you changed a cluster constant from horizontal to vertical

I remembered a couple more:

I like the new .lvlib libraries. I just find it funny that they allow you to use VIs of the same name in your program but when you compile it into an executable you get a warning that you have VIs with the same name and those are automatically copied into folders outside your executable. Would it be so difficult to prepend the library name during the build process?

I have never tried this with inherited classes in which the override VIs have to have the same name. Does the same thing happen during a build?

In the project tree, for each virtual folder, class, library, etc. you have a function to Arrange the containing files (by Name, etc.). Why does it not remember that setting? Every time an item is added or created in a folder I have to re-arrange. :headbang:

[LAVA 1.0 Content]

QUOTE (hfettig @ Jul 25 2008, 10:47 AM)

Ah yes, Auto-Groan. Especially annoying when you have nested structures that all grow. And all just because you changed a cluster constant from horizontal to vertical

I remembered a couple more:

I like the new .lvlib libraries. I just find it funny that they allow you to use VIs of the same name in your program but when you compile it into an executable you get a warning that you have VIs with the same name and those are automatically copied into folders outside your executable. Would it be so difficult to prepend the library name during the build process?

I have never tried this with inherited classes in which the override VIs have to have the same name. Does the same thing happen during a build?

In the project tree, for each virtual folder, class, library, etc. you have a function to Arrange the containing files (by Name, etc.). Why does it not remember that setting? Every time an item is added or created in a folder I have to re-arrange. :headbang:

THe SOurce Distribution now has an function that will automacially prepend text to VI names.

Ben

[jgcode]

Well I am stoked with LV8+

Having to program in LV5 on a recent job and that my friends.. suck...

Anyway one thing from me....

I would like a "remember last selection on cancel".

E.g. I pick a while loop and accidently place it in the wrong spot (e.g. miss encapsulating VIs).

I want to hit undo but for the cursor to "hold onto" that structure.

If I still do not want the structure I can just hit escape.

9 times out of 10 I will want to use it again and have to go through all the palettes.

Ok for a while loop but annoying when there is many layers to get to a structure from the Functions palettes.

JG

[jzoller]

QUOTE (hfettig @ Jul 25 2008, 07:01 AM)

I thought I'd start a topic about pet peeves with regards to the LabVIEW development environment.

Maybe it is just me being ignorant and somebody knows a way around these things.

Maybe you have some pet peeves too that you would like to share.

...

Occasionally, the LV IDE drives me batty. Just totally, 'why isn't this available?!!!', stark, raving nuts. After calming down a bit, I ran across the reason.

In Jeff K's very good article http://zone.ni.com/devzone/cda/tut/p/id/5313' target="_blank">Is LabVIEW a general purpose programming language?, he states:

"In reality, it is a severe disadvantage to limit the connection between program editor and program compiler to a simple ASCII stream."

This model has worked well for LabVIEW, but it has a very dark side.

Go off to the nearest OO-style program you have available. Find two well factored, separate classes. Great, now combine them into a single class.

What's that? Loose coupling between different functions? Ah, but, there *are* benefits to tight coupling: information sharing is very tight, and you can have very strong optimization, because your environment is very well known. These benefits are most obvious in the first few versions.

As things evolve, though, you run into a problem. You must develop the components together. Lockstep. You can't make changes to the IDE without affecting the compiler, and vice versa. And so, the combined component takes *at least* twice as much time to develop, and probably more due to developer communication overhead, and when one component introduces side effects into the other.

And so, when your competitors are introducing scriptable development environments, code snippets, plugins, etc... you still take 9 steps to make a merge VI. You can't right click a selected portion of code and say "Put a for loop around this". You can't select a sub-vi and see it's path in the IDE. You can't adjust the speed of the debug highlighting. You can't match sizes on the block diagram. You can't attach the profiler results to the VI hierarchy display. You can't modify palettes on the fly. You can't have a scrollbar on a cluster.

So, the industry standard solution to all this is painful: intermediate bytecode/markup, generated by the IDE/precompiler and consumed by the compiler. Whether that, or something more innovative, would ever happen, is difficult to say.

Happy Friday,

Joe Z.

[Norm Kirchner]

QUOTE (hfettig @ Jul 25 2008, 08:01 AM)

The third one is has to do with the fact that you cannot select a bunch of similar controls and change properties for all of them at once. I

I bet that this is already in the works, but don't quote me on that.

As a minimum, get involved in the LV scripting end of things on the forum.

Turns out that by using the [selected] property of a FP or BD you can do wonderful things w/ some Very simple code assuming you've selected all the same type of control.

See below.

I agree that it's not as simple as having it native, but it gets you close to the point of only making it a minor annoyance rather than reaching the level of peeve.

http://content.screencast.com/users/NJKirchner/folders/Jing/media/b0e2f532-64dd-420f-8817-32767a4e4206/2008-07-25_1102.png' rel='nofollow'>

[crelf]

QUOTE (jzoller @ Jul 25 2008, 11:47 AM)

Occasionally, the LV IDE drives me batty. Just totally, 'why isn't this available?!!!', stark, raving nuts. After calming down a bit, I ran across the reason.

Great post, but the reason I most often see is much simpler than that: no one has asked for it I find NI to be pretty responsive to new IDE feature requests (based on valid use cases, of course).

[Darren]

This thread makes me think of two things. First, make sure y'all submit suggestions for any LabVIEW features you want to the Product Suggestion Center. I promise we do actually read every single one that comes in, and the more similar ones we get from different people, the higher the chance it will become a feature someday. Second, perhaps this thread would be more effective if it were a LAVA Wiki entry? I envision a list of feature requests on a Wiki page, and it can be updated after every LabVIEW release by moving things from the "requested" list into the "hey, it's a feature now!" list.

-D

[jzoller]

QUOTE (crelf @ Jul 25 2008, 10:19 AM)

Great post, but the reason I most often see is much simpler than that: no one has asked for it I find NI to be pretty responsive to new IDE feature requests (based on valid use cases, of course).

Actually, I've never found NI to be unresponsive (though the response might just be "No", or "We can't tell you right now"). They are responsive, open, communicative, even chatty, and I love that about them. The difficulty that I see is implementation time.

When was the first time you requested "change all at once" feature that Heiko & Norm mentioned? I know it was LV5.1 for me, undoubtedly due to some hideous, gods-awful megacluster I had conjured up... anyway.

I don't think that it's lacked implementation for all these years because they didn't know about it, or were avoiding it, or weren't working their butts off trying to make LV the best possible system. My suspicion is that it hasn't been done because it's just hard, and difficult things take longer, and get pushed down the priority list. Frankly, if the choice was between that feature and, say, Retain Wire Values, I'd take Retain Wire Values in a heartbeat.

Design decisions always have tradeoffs, and this is the one we live with: we get the best integration between IDE and compiler anywhere, that does things that many programmers don't even believe can exist. In return, we suffer the occasional leaky abstraction and trailing a bit behind on some of the more modern IDE features.

Joe Z.

[LAVA 1.0 Content]

QUOTE (jzoller @ Jul 25 2008, 02:27 PM)

...

My suspicion is that it hasn't been done because it's just hard, ...

There is one more complication that I can think of....

Trying to hit a "moving-target" without introducing bugs. None of us has managed to coble together this function using scripting such that it works for all object types. NI has another challenge in that they have been adding or modifying FP objects. Not to mention the wide spectrum of abuse we (the users) could subject it to, example, I select a boolean and an array of clusters and then use this new mega-tool and to set the font style. Is it the lable font?, the font in the cluster?....

THey have managed to let us set the dimensions of all objects since all LV objects have that in common.... (except decorations?).

Ben

[jdunham]

My pet peeve is the file dialog box. It's great that it starts in the last folder you accessed. However, only one last position is remembered, and it's shared between opening up VIs and other code from the File menu, versus opening data files from various runtime methods of opening files. Only a crazy person keeps programs and data anywhere near each other on the hard drive, and it's very irritating to have to navigate back and forth.

This gets even worse if you have parallel branches of similar code (managed with a professional source code control system, of course). Right after you switch branches, it is very easy to browse into the wrong working copy on your hard drive, since the folder structure is usually identical, and LV's file dialog box will almost always start you in the wrong one.

With the miracle of lvproj "application instances" you can have both trees open at the same time, and the file dialog box will work as hard as possible to encourage you cross-link your code. Often, loading the VIs with throw warnings which you ignore at your peril, but the right place to fix this is in the file dialog box starting place.

My wishes:

1. For loading VIs, it should always start in the lvproj folder or one of its subfolders

2. For loading data files with File VIs, path control browse buttons, executing the file dialog function, etc, it should maintain a separate "last used folder" amd start there.

I have already submitted something like this to the LV product suggestion center, but I encourage others to do so too.

[LAVA 1.0 Content]

QUOTE (jdunham @ Jul 25 2008, 10:39 PM)

1. For loading VIs, it should always start in the lvproj folder or one of its subfolders

Saving a LabVIEW file (control/VI/class/library) should be done in the active project folder, a LVproject should open up in the LabVIEW data folder.

My Pet Peeves:

1. Case structures
   They have the bad bug invitable following behaviour:
   If you change the selector type from Boolean to another the 'False' diagram gets the label of the '0' element and default, and the 'True' diagram gets '1'.
   For enums this is not acceptable, their should not be a default case by default.
   For strings the first case could be labeled 'Default' and the second '""' (empty string). But IMHO there shouldn't even be labels. How many times do we forget about the 'False/Default' case.
   Numerics have the plain bad behaviour.
   My point:
   Default is a choice not a default value.
   
2. The application builder should have 'Conditional disable structures' options.
   
3. It should be easy (right-click easy) to name a pane and splitter
   

Ton

[Yair]

QUOTE (hfettig @ Jul 25 2008, 04:01 PM)

The third one is has to do with the fact that you cannot select a bunch of similar controls and change properties for all of them at once.

Like Norm, I wouldn't be shocked if this appeared in a future version.

QUOTE (neB @ Jul 25 2008, 04:12 PM)

Auto-grow (auto-explode) option is true by default.

It's a good thing NI doesn't let you design LabVIEW. :laugh:

Ignoring the discussion of whether auto-grow is good or not (I think it's essential as another means to avoid having bugs), the default option for everything should be what the novice user needs, not what the advanced one needs. The advanced one can either change it or use their old INI file.

QUOTE (jdunham @ Jul 25 2008, 11:39 PM)

My pet peeve is the file dialog box. It's great that it starts in the last folder you accessed.

This is done by the OS, not by LabVIEW. To work around that, LabVIEW would have to use its own file dialog (which it does have and which you can select in the options screen (although I suppose it is hypothetically possible that LabVIEW could remember the last path and feed it itself into the dialog. That would of course have to be implemented and tested on all three platforms). Personally, I just use TweakUI and set the folders on the left to five folders I'm likely to use.

By the way, you should note Darren's suggestion of going to the product suggestion center.

[LAVA 1.0 Content]

QUOTE (jdunham @ Jul 25 2008, 10:39 PM)

My pet peeve is the file dialog box.

QUOTE (Yair @ Jul 26 2008, 09:33 PM)

This is done by the OS, not by LabVIEW. To work around that, LabVIEW would have to use its own file dialog (which it does have and which you can select in the options screen (although I suppose it is hypothetically possible that LabVIEW could remember the last path and feed it itself into the dialog...)

Well if we open up a browse dialog from LabVIEW we can set the 'start path' from where the dialog will open.

Why can't LabVIEW do such a thing?

Ton

[Michael Aivaliotis]

QUOTE (jdunham @ Jul 25 2008, 01:39 PM)

My pet peeve is the file dialog box. It's great that it starts in the last folder you accessed. However, only one last position is remembered, and it's shared between opening up VIs and other code from the File menu, versus opening data files from various runtime methods of opening files. Only a crazy person keeps programs and data anywhere near each other on the hard drive, and it's very irritating to have to navigate back and forth.

You could try http://wiki.lavag.org/LabVIEW_configuration_file/Miscellaneous#MRUFolders' rel='nofollow' target="_blank">this ini setting (MRUFolders). It helps a little. Don't know if it works in 8.5.

[Jeffrey Habets]

QUOTE (Ton @ Jul 26 2008, 11:28 AM)

The application builder should have 'Conditional disable structures' options.

Amen to that..

QUOTE (Ton @ Jul 26 2008, 11:28 AM)

It should be easy (right-click easy) to name a pane and splitter

Imho this is already possible.

Right clicking the splitter gets you to the visibility property of the label for the splitter as well as the adjoining panes. From this menu you can also open a properties dialog for the panes and change the label there, which is easier if the label is obstructed by controls on your pane.

The splitter itself though doesn't seem to have a properties dialog. I wonder why, since all other controls have one.

[Aristos Queue]

QUOTE (Ton @ Jul 27 2008, 12:24 AM)

Well if we open up a http://zone.ni.com/reference/en-XX/help/371361B-01/glang/file_dialog/#Inputs' target="_blank">browse dialog from LabVIEW we can set the 'start path' from where the dialog will open.

Why can't LabVIEW do such a thing?

It can. You may notice that the first time you save a VI that is a member of a library, you're directed to the same directory as the library itself. That little tweak appeared courtesy of the LVClass team, which got really tired of dynamic dispatch VIs getting saved over each other.

When Yair says this is done by the OS, he's kind of right --- in the absence of other directives, the OS tracks the last used directory. In the past, this was less of an issue, but as LV has become more of a "large app" tool, I can understand the pervading frustrations.

[Yair]

QUOTE (Aristos Queue @ Jul 27 2008, 11:43 PM)

When Yair says this is done by the OS, he's kind of right --- in the absence of other directives, the OS tracks the last used directory.

Yes, that's what I meant. Windows does this by process name, and since all LabVIEW processes are named LabVIEW.exe, working in a folder in one LabVIEW version would mean that when you use another version you would get the same folder, even though the code in that folder is saved in the first version. Fun, fun, fun. As I said, I just use a custom places bar.

[ragglefrock]

I'll throw in my pet peaves about the editing environment. They're small individually, but over the course of the day they cause me to lose a lot of time and patience!

1. There are no keyboard shortcuts for specific alignments of block diagram objects. Yes, I know you can hit Ctrl-Shift-A to redo the last alignment, but that causes me to remember what the heck the last alignment was, which is often not what I want to use this time. I would be willing to memorize a few extra keyboard shortcuts to get the alignment I want (left, right, up, down). For instance use the numeric keypad and have Ctrl-Shift-4 for left alignment, Ctrl-Shift-6 for right alignment, etc. I do this about 50 times a day (slight exaggeration), and it's always a pain point not to have an automated method.
   
2. Creating block diagram space in one dimension only. I very rarely ever want to create space in two directions, because that can completely screw up the alignment of the whole block diagram. I almost always want to create space in one direction, so I have to very carefully make sure I only Ctrl-drag in one direction. One pixel off and I have to redo the operation. Very annoying.
   

Ok, I'll throw in another one which is definitely more like a feature request than a pet peeve, but it's close enough:

When you have an array control or constant, you can add or remove dimensions through the right click menu (very cool). But you can't bridge the gap between scalar and vector items in the same manner. So it's always annoying when I have an array control and I want to replace it with a scalar of the same type. I usually end up deleting the control and starting from scratch, which makes me reconnect it to the Connector Pane. Same goes for a constant. I'm tired of dropping down empty array shells to create arrays of things.

What would be really cool would be an automatic right-click menu option to do this. Right click a scalar of an appropriate type (non-waveform, non-xcontrol), and you get an option to Change to Array. Right click a 1D array and instead of Remove Dimension, you see Change to Scalar.

This would make life easier, and conceptually I think it's a pretty straight-forward continuation of the Add/Remove dimension idea.

[boone_93]

QUOTE (ragglefrock @ Jul 28 2008, 01:04 PM)

I'll throw in my pet peaves about the editing environment. They're small individually, but over the course of the day they cause me to lose a lot of time and patience!

1. There are no keyboard shortcuts for specific alignments of block diagram objects. Yes, I know you can hit Ctrl-Shift-A to redo the last alignment, but that causes me to remember what the heck the last alignment was, which is often not what I want to use this time. I would be willing to memorize a few extra keyboard shortcuts to get the alignment I want (left, right, up, down). For instance use the numeric keypad and have Ctrl-Shift-4 for left alignment, Ctrl-Shift-6 for right alignment, etc. I do this about 50 times a day (slight exaggeration), and it's always a pain point not to have an automated method.
   
2. Creating block diagram space in one dimension only. I very rarely ever want to create space in two directions, because that can completely screw up the alignment of the whole block diagram. I almost always want to create space in one direction, so I have to very carefully make sure I only Ctrl-drag in one direction. One pixel off and I have to redo the operation. Very annoying.
   

Wow, I totally agree with both of these, it's almost like another person was typing for me :thumbup:

QUOTE

Ok, I'll throw in another one which is definitely more like a feature request than a pet peeve, but it's close enough:

When you have an array control or constant, you can add or remove dimensions through the right click menu (very cool). But you can't bridge the gap between scalar and vector items in the same manner. So it's always annoying when I have an array control and I want to replace it with a scalar of the same type. I usually end up deleting the control and starting from scratch, which makes me reconnect it to the Connector Pane. Same goes for a constant. I'm tired of dropping down empty array shells to create arrays of things.

What would be really cool would be an automatic right-click menu option to do this. Right click a scalar of an appropriate type (non-waveform, non-xcontrol), and you get an option to Change to Array. Right click a 1D array and instead of Remove Dimension, you see Change to Scalar.

This would make life easier, and conceptually I think it's a pretty straight-forward continuation of the Add/Remove dimension idea.

Never thought of it that way until you said it, again I totally agree.

Dan

[ned]

QUOTE (ragglefrock @ Jul 28 2008, 02:04 PM)

When you have an array control or constant, you can add or remove dimensions through the right click menu (very cool). But you can't bridge the gap between scalar and vector items in the same manner. So it's always annoying when I have an array control and I want to replace it with a scalar of the same type. I usually end up deleting the control and starting from scratch, which makes me reconnect it to the Connector Pane. Same goes for a constant. I'm tired of dropping down empty array shells to create arrays of things.

What would be really cool would be an automatic right-click menu option to do this. Right click a scalar of an appropriate type (non-waveform, non-xcontrol), and you get an option to Change to Array. Right click a 1D array and instead of Remove Dimension, you see Change to Scalar.

While this is annoying, you can (at least in my opinion) partly solve this by taking advantage of the fact that pasting a front panel object while an object on the front panel is selected causes the selected item to be replaced, leaving the connector pane wiring intact. So, if I have an array control and want a scalar, I'll drag (or control-drag, for a copy) the item out of the array control, cut it, select my array control, and paste.

What I don't understand is why you can't do this for block diagram constants - on the block diagram, paste places a new object rather than replacing the selected one.

[eaolson]

The one that annoys me the most is that, when you paste a local variable onto a block diagram, LabVIEW instead creates a new control/indicator and pastes in a local variable for that, instead of the original. It's "copy and paste," not "copy and paste in something kinda similar." The location of the new terminal isn't predictable, often winds up halfway across the diagram, and resizes any loops that are set to Auto-Grow.

What I always wind up doing is undoing the paste, control-dragging the local to some free area of the diagram, and dragging it into position.

[ned]

This one is pretty minor but I run across it regularly: on a block diagram, when I right click on a "Compound Arithmetic" primitive and navigate to the "Replace" menu the options are "Numeric Palette" and "All Palettes" even though the wires running into the node are booleans. Can we have a shortcut to the boolean palette there too?

[Yair]

QUOTE (hfettig @ Jul 25 2008, 04:01 PM)

The third one is has to do with the fact that you cannot select a bunch of similar controls and change properties for all of them at once.

http://zone.ni.com/devzone/cda/tut/p/id/7336#toc0' target="_blank">Hmm...