LabVIEW Idea Exchange

How is NI-MAX still so bad after all these years? It goes completely unresponsive and crashes at the slightest provocation. This feels like it should be NI's bread-and-butter.

Every LabVIEW team ends up recreating so much of the functionality that NI-MAX is supposed to offer out of the box. Maybe with the discontinuation of NXG, some resources should be allocated to making this product usable.

KB articles like this and this probably shouldn't need to exist.

Tunnels for FOR loops are autoindexing by default. Sometimes this is not the correct option for very obvious reasons and we get a broken wire.

The diagram editor should be smart enough to try the "other" option (e.g. no autoidexing) if a broken wire results. If the other option succeeds without a broken wire, it should be used automatically. Maybe the tunnel could "glow" for a few seconds with a small option box (similar to e.g. when pasting into word: keep formatting, text only, etc) that would disappear after a while where we can click and overwrite the automatic handling.

The image shows two wires that would be a candidates for autocorrection of the indexing option. In both cases, LabVIEW should disable indexing automatically to avoid broken wires.

If both options result in a broken wire, nothing should happen, as before.

(Similarly for while loops. e.g. if I wire a scalar across the boundary to an array indicator, it should autoindex.)

It's very frustrating to have your floating probe windows disappear when a LV modal window is presented. Frame 1 below shows probes set up, and Frame 2 shows how they disappear when a modal window appears:

Some of the most annoying modals that pop up while troubleshooting include: 

1. "Save changes before closing?"
2. "Waiting for Real Time Target to respond"
3. Error windows

#2 and #3 modals windows recently made it impossible to use probes since I was trying to diagnose a problem that constantly would throw those modal windows.

Proposed Solution: Don't ever hide probe windows, regardless of what pops up.

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

Strict typedefs and non-strict typedefs differ significantly.  There's too much of a gap for me.  Sometimes I'd love a control to be somewhere in between.

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked.  That way we could shoose to long only boolean text, width or colour but leave the other properties free.  VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.