Worst LabVIEW design feature

[GregSands]

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

What design feature in LabVIEW most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about?

In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth.

OK, your turn.

[Black Pearl]

QSM

Felix

[ShaunR]

I'm not a fan of the Image type for the vision stuff either. I keep getting caught out even though I know how it works.

A lot of vision stuff I do requires acquiring and image then creating various masks and applying them (often one after the other or in various combinations). The UI though, normally requires showing of original images and the results of the various stages of mask applications therefore you end up copying everywhere so as not to overwrite the originals or the intermediate results of a mask. It gets very messy

But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

[dannyt]

But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

Oh I so agree with the new probe window. I think a number of the "windowed" IDE addon's are like that, only half thought out in usability terms. The heirarchy view is next to useless in any real way.

Dannyt

Edited December 16, 2010 by dannyt

[ShaunR]

Oh I so agree with the new probe window.

Dannyt

Especially as you used to be able to change probe properties and resize the controls (like being able to view strings as hex). Or maybe I dreamt that

[Grampa_of_Oliva_n_Eden]

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

What design feature in LabVIEW most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about?

In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth.

OK, your turn.

1) "annoyed" past tense. Remember the Just in Time Advise thingy that peoples started calling "Spoolie"?

2) "Shared Variables" lets take the danger of globals and allow the devlopment of race conditions across platforms? While we are at we can tell the world they are the answer to everything, and lets lock down all of the functionality so users have to wait half a year to get a fix (maybe) and for bonus points let's make our DSC product dependent on them... Wait... We can move all support for the low level stuff to another continent and implement a 24 hour e-mail delay in replies like "BridgeVIEW? I don't know BridgeVIEW, but it was supposed to be like DSC." Yes the quagmiere of treading between "Yes I recomend using LV for this project." and "No, I am not going to take NI's advise to use SV's." can leave a mark on you.

Ben

[hooovahh]

The tree control has always been difficult to work with, but since there has been some community support it has become easier to work with.

Maybe the fact that the run time engine balloons with every version. Making a 100MB install for a "Hello World" program doesn't seem very useful, but then again Hello World isn't all that useful anyway. Really it would be great if some basic LabVIEW runtime engine was included in Windows, but that'll likely never happen.

Version dependent issues really suck. You can save up but now down very easily. It would be nice to be able to open a LabVIEW 7.1 VI in 8.2 and when I save let it have the option to save in 8.2 or 7.1 compatibility. (obviously wouldn't work if you use a feature that wasn't in 7.1). Again I don't expect this to ever happen. Other version dependencies issues are anoying too. Say I have LabVIEW 8.0 installed, what versions of MAX work with it? What versions of DAQmx work with it? Traditional DAQ? FPGA? NI-RIO? NI-CAN? Switch? Now what hardware work with what software? Are there some DAQ cards that only support DAQmx? Where is the tables and charts showing these dependencies?

[PaulG.]

I would have to go along with the new probe window. And the icon editor is CRAP. And the lack of any real new design of front panel controls - ever.

[Daklu]

Insufficient customization options over the development environment.

There are lots of actions I'd like to assign keyboard shortcuts to but can't. I'd like to be able to create custom toolbars move them around where I want. Menus (especially right click menus) are overpopulated and I wish there was a way to make them "smart" where they show items that are used frequently and offer a way to quickly expand to see all the options.

QSM

Oh I so agree with the new probe window. I think a number of the "windowed" IDE addon's are like that, only half thought out in usability terms. The heirarchy view is next to useless in any real way.

I actually like the new window better than the old style. When I have a lot of probes going I find it very useful to be able to refer to a single list of probe values that describes the application's state at any one time. That said, the UI definitely needs usability improvements. Resizing the window in particular is implemented all wrong.

[vugie]

New fancy 3D charts. Do you also and when you accidentally put one of them on the front panel?

[asbo]

But more generally, the "probe window" introduced with LV2009.

It really wouldn't be so bad if I could open the probe in a new window AND close the parent window ... and if we're going to get timestamp tracking in the parent window, why not find a way to show that in the floating window too??

[jzoller]

The marketing.

It's tiring having to continually defend LV (and therefore my budgets) as a "real" language.

[Jarrod S]

QSM? That's not a LabVIEW feature. Also, there are many many different ways to do QSMs with many different advantages and disadvantages. If poorly developed, then yes, they are a pain. But nothing protects against bad code.

Probe Window: Big yes. Terribly painful. Off the top of my head here are the biggest pain points:

• It's a floating window, so it's forced to stay on top of other windows. Why?!? Don't force this behavior on me! Why is it shocking that I'd want to view other windows on top of the probe window?
• Since it's floating and I can't put it behind other windows, I regularly minimize it. However, probing a new value does NOT restore it! Wrong wrong wrong.
• Generic probes don't resize to fit the large amount of space they now have. This means that numeric and string probes only show a small fraction of the content, with no means of seeing it all (other than creating a new probe type).
• The dialog remembers its last size, but gets confused if it was last maximized. It tries to set its new size to be the size of your monitor, but it is not in a maximized state. Wrong wrong wrong. This forces you to manually restore it to a normal size. I HATE this. Especially when it's so common that you want to maximize the probe window to get the most out of it.

Shared Variables: Definitely agree. Now that you can dynamically read and write to them, why can't you programmatically create Shared Variables on the fly without the DSC module?

[hooovahh]

Auto tool (you're welcome asbo).

[soupy]

I love LabVIEW and it lets me develop dependable code quicker than anyone thought possible for a decent price. I'm sorry NI, but this is for your own good. You'll thank me one day.

• LabVIEW is the Apple of programming languages. You are only allowed to do what NI thinks you are smart enough to do. A little less hand holding would be nice. (I swear I'm smart enough to not create race conditions)
• It took you 25 years to develop a pointer (DVR) to data? really?
  • yes, i understand 1EQs have been around for some time, but they are kind of a hack

  [*]File dialog globally remembers last path[*]"lost" files in classes/libraries/xcontrols cannot be replaced with a file name that differs from the original lost file[*]ctrl+drag (the operation that "makes" space on the FP/BD) can't be disabled

  • ever blow a hole in a case structure with 20 cases?
• datasocket/shared variables unpredictably gain/lose bugs every release cycle
  • causes me to go through weeks of DS/SV qualification testing every time we upgrade
  • Network malfunctions/dropouts are highly visible to end users. #1 reason why my upper management doesn't think LabVIEW is a real programming language.
  • would drop DS completely and go with SV, but i don't wanna buy DSC for security features that were included in DS
  • going to raw TCP/IP communication as soon as i can.

  [*]LabVIEW Developer Suite does not include developer tools

  • Express VIs don't count as developer toos
• Most webcasts/Virtural User Group presentations either cover basic/intermediate new user training or around something NI wants you to buy.
  • Why can't they just be about becoming a better advanced programmer? Or how about an advanced application developer?
  • You want to be a real advanced programming language, but you aren't giving your customers the tools to become advanced developers.
  • The large application user group is a great example of this. gimme more!
  • Most of us do not have computer science backgrounds. Anything you can do to bring in CS concepts and strategies would be appreciated.

  [*]Front Panel objects are outdated

  • #2 reason why my upper management doesn't like LabVIEW (a.k.a it doesn't look cool)
  • customizing objects is difficult and kludgy. because of this, i don't have time to make things look pretty.
  • if you released a front panel control dev tool, the NI community would solve this issue for you

Ok, now I'm done hatin...back to work.

[Ton Plomp]

There are lots of actions I'd like to assign keyboard shortcuts to but can't. I'd like to be able to create custom toolbars move them around where I want. Menus (especially right click menus) are overpopulated and I wish there was a way to make them "smart" where they show items that are used frequently and offer a way to quickly expand to see all the options.

XControls are your friend sir.

About the probe dialog, what I don't like is the fact that the new dialog gets focus after creating a probe. It's a major step back in quick debugging (and that for a prototyping language):

1. A VI with unforseen outcome
2. Drop a probe
3. hit ctrl-r (run)
4. nothing happens
5. ....
6. Oh yes, the probe dialog has focus
7. Switch back to VI
8. hit ctrl-r
9. find bug

Ideally that would be a 3 stepper.

Auto tool (you're welcome asbo).

Don't reject the auto-tool! You are like Apple (who needs more than one mouse button?)

Ton

[Antoine Chalons]

icon editor

[ShaunR]

Do you reckon this is going to be longer than the "Like" thread Everyone loves a good moan

+1 for any user interface stuff

Edited December 17, 2010 by ShaunR

[hooovahh]

You are like Apple (who needs more than one mouse button?)

Ton

What do you even mean by this? Who needs more than one mouse button? ...Me, my mouse is a 17 button with scroll wheel that also has a middle click (so I guess 18 buttons) To be fair I only use 5 of the buttons, but I don't see how not liking the auto tool means I like one mouse button. If anything it means I like using more than one mouse button for Shift + Right click.

[ShaunR]

What do you even mean by this? Who needs more than one mouse button? ...Me, my mouse is a 17 button with scroll wheel that also has a middle click (so I guess 18 buttons) To be fair I only use 5 of the buttons, but I don't see how not liking the auto tool means I like one mouse button. If anything it means I like using more than one mouse button for Shift + Right click.

I'm not an auto-tool fan either. It wires when I want to select and you have to select breakpoints and colour chooser anyway.... drives me mad. I'm a Tab and space-bar freak.

[Grampa_of_Oliva_n_Eden]

I'm not an auto-tool fan either. It wires when I want to select and you have to select breakpoints and colour chooser anyway.... drives me mad. I'm a Tab and space-bar freak.

Put a mark in the Auto-tool select for me as well. I have tried it in various releases and although getting better, it eventually guesses wrong bringing my work to a stand-still. Shift-right-click shut-it-off and I am done experimenting until the next release of LV.

Ben

[vugie]

What you guys have against auto tool?... I use it all the time with only exception for picking colors (BTW it is ^$**#^#*#$@%$)

[soupy]

I don't understand the auto-tool hate.

1.) It is an option, you can turn it off.

2.) Its function is based on what pixel you are hovering over. Memorize the pixel context, turn down your mouse sensitivity and quit complaining.

3.) Yes, it doesn't switch to the paintbrush tool, but if you bind the tools palette to Ctrl+T (who tiles windows anyway?) then you're in business.

Seriously, auto-tool gets the job done if you know how to use it. Your inability to use a tool doesn't invalidate its usefulness.

[Antoine Chalons]

I don't understand the auto-tool hate.

Yep, I have to admit I hated it for a long time and eventually my dad convinced me that it was worth trying, I tried and never turned it off since.

And now the few of my colleagues who (still) dont' use it get crazy at me when I turn it on on their computers

[Grampa_of_Oliva_n_Eden]

I don't understand the auto-tool hate.

1.) It is an option, you can turn it off.

2.) Its function is based on what pixel you are hovering over. Memorize the pixel context, turn down your mouse sensitivity and quit complaining.

3.) Yes, it doesn't switch to the paintbrush tool, but if you bind the tools palette to Ctrl+T (who tiles windows anyway?) then you're in business.

Seriously, auto-tool gets the job done if you know how to use it. Your inability to use a tool doesn't invalidate its usefulness.

It is not hate but frustration. In my case I have to work on everything from LV 5 through 2010. Which means sometimes the auto tool is there and other times it is not or is a differnt flavor. If I get in the habit of using auto-tool then show-up at customers sight and start acting baffled when the auto-tool is not working on a LV 5 mahcine, i will look like .... not a LV expert.

THe tabs and space work on all versions and I don't even have to think about how many clicks from ths to that any more and besides, I can do the tool selection while the mouse is in transit so I have to right toll ready BEFORE I get there and not after.

Ben