LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

I've got some code on my diagram:

I need to wrap the code in a case structure, so I do:

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up. This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

Classes? OOP? ... Huh?

Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!

The problem:

Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.

Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:

Opening the "class properties" window takes 10 seconds or more
Renaming a class brings the editor to a standstill

For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!

Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.

The idea:

Improve the responsiveness of the LV editor when working with classes.

Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!

Credits:

Others have written about this topic well before me. Here are a few relevant discussions:

Feel free to link more!

View All (7)

Mass open/close branch in Project

View All (1)

I have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes). This one item would expand the UI possibilities. It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets. Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

Microsoft Word 2010 Splash Screen (No border, rounded corners)

Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

View All (2)

Make Shift+Drag more usable

Pressing Shift and dragging an object with the mouse make it move only horizontally or vertically. Great!

Unfortunately Labview decides which direction to move (horizontally or vertically) based on the first pixel the mouse moves. So, if you want to move something horizontally, but while clicking your mouse moves one pixel vertically, you're stuck with that direction and can start over again. ☹️

"Normal" applications decide the direction to move based on the ratio of x/y mouse movement: If the mouse moved more in vertical direction, the user obviously wants to move that way, if the mouse moved more in horizontal direction, then that is the user's intent. This means you can switch the direction while dragging and you're not stuck to one direction!

PLEASE modify the annoying behavior of Labview accordingly!

View All (1)

It's a little annoying to try to draw long wires to a terminal that's currently off screen -- you have to hold your mouse at the edge of the screen and LabVIEW slowly scrolls the window (Shift will speed this up a little bit). Currently, neither the mouse wheel nor the touch pad work for panning/scrolling while a wire is currently in progress.

As an improvement, it would be great if the mouse wheel allowed panning the diagram while the new wire was still in progress.

See the attached video.

View All (1)

DIff String Constants in LVCompare

Wire bend issue to numeric nodes

Hello,

As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.

So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.

So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.

View All (1)

This is a very small suggestion, and hopefully easy to implement. When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires. All I'm asking is that Error wires are always placed underneath all other wires when they are created. To my mind, this improves the readability of the diagram.

What would help further is if Error wires were "faded", as if they were 50% transparent. You do need to be able to see them, but not such that they stand out. But I'm much less certain that such a change could happen. The khaki color is an improvement on the old pink though, that's for sure!

View All (6)

Immutable Boolean constants

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

View All (2)

When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.

Issue:
Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)

Proposed feature: Trends
It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends.

Proposed feature: Automated Analysis
Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).

I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.

If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation

I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.

This recent idea reminded me of something I have wanted for quite some time now: the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.

The basic idea is simple: all properties have two terminals, one for writing and one for reading (except read-only of course). No right-clicking, just wire up the direction you want.

The bottom case is a bit interesting. I see a few possibilities:

1. Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.

2. Read then write : returns previous value. What happens if there is an error? Passthrough, old value?

3. Write then read: almost always passthrough. In case of error would it return old (ie. actual value) or passthrough?

4. Do not allow this.

I would expect it to perform the write and then the read (3) or passthrough (1). What is more important to me is the actual value and not the intended value. Mentally I just see data flowing into then out of the PN when both are wired.

Bottom line: I see no reason not to permit the wiring to determine read or write of a property.

If there is a ~~cop-out~~ lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list. Then I could at least do the write+read with a lot less mouse movement.

View All (1)

glyphs in case structure menus

Another for the wish list.

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

See attached pic for an mock up.

There are probably lots of menus that could benefit from something like this.

View All (1)

LabVIEW Idea Exchange

Optional (and easily-dismissable) prompt to change newly-dropped case structure frame to FALSE

Drill-down debug capabilities for class overrides

Improve IDE performance when working with lots of classes

Mass open/close branch in Project

Overrides of interface methods that have error in/out terminals should wire the error by default

"Why is this item in Dependencies" should only show items that are directly dependent on it

Allow Panel Background Color to be Transparent

Make Shift+Drag more usable

Allow mouse wheel(s) to pan diagram while wiring in progress

DIff String Constants in LVCompare

Wire bend issue to numeric nodes

Always place Error Wires underneath other wires

Immutable Boolean constants

Move Conditional and Iteration to the "Visible Items" submenu

Conditional Indexing to optionally output the false condition (along with the true one)

Trends and analytical features in the Profile Performance and Memory tool

Build specs should NOT silently remove items if they are deleted on disk

Remove auto-generated information from LabVIEW project file

Allow Wiring to Determine Property Node Read/Write

glyphs in case structure menus