LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Swap Long

View All (1)

Probe Watch Window (Reset Index)

Reset the Probe index when the <Probe Watch Window" is closed

above, the probe index equal 18, however only one probe is active.

When you close the <Probe Watch Window> ...therefore when you close all probes,

in this case, reset the probe index for the next time.

It's useless and annoying to have a probe index equal to 18 (sometimes much more),

when only one probe is active. Thank you.

Currently: When you "Find Missing Items" in a project, it thinks a few seconds (on a large project) and pops up a non-resizable window. You can double click on an item in the list, which closes the Missing Items list and it highlights the missing item in the project. You remove that item (or relink it) in the project, and then have to "Find Missing Items" again. Wait a few seconds, rinse, repeat...

Proposed:

1. When you double click on an item in the Missing Items list, do not close the list - leave it open, and gray out items that have been taken care of and are no longer "missing" (like the find dialog, when you delete a found item).

2. Allow the columns to be sorted by clicking on the header Name, Location in Project, or Path (this one holds a dear place in my heart)

3. Finally, allow the window to be resizable (a common request...).

(I have given the example for "Find Missing Items"... you can apply the same concepts to "Find Items with No Callers")

Message Edited by mechelecengr on 08-26-2009 02:19 PM

View All (5)

View All (4)

Data Aware QuickDrop Results

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire. Lets say I have a 1D array of numerics selected and I want to reverse it. I will select the wire, then invoke QD and type "reverse". But the first item in the list is actually "Reverse String". With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.

This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster). But we could also use this on class wires that are selected. A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up. So this idea could also prioritize functions that are found in the mnu associated with the class.

Hello all,

I find myself constantly tweaking my wire labels so that they look like they are exactly vertically centered on the wire, rather than a couple pixels higher or lower. They are not always created that way, and of course when you move the wire around they don't stay that way like I wish they would.

I'd like to propose an option to have LabVIEW automatically force wire labels to stay vertically centered on the wire (similar to other "snap-to" label positionings). I know that other programmers prefer other positions, such as immediately above the wire, therefore having it snap to that position would be another option. I'm not sure if it makes more sense to select one position that it always snaps to, or have it snap to one of a few options (like labels on controls do now). I always use them consistently in the one vertical position, myself.

It may make sense to have the default be free-positioning as it stands today, but it would save me a non-trivial amount of time to have the option for it to be always enforced to what I think looks nice. Hopefully I'm not the only one!

Obligatory pictures:

Initial vertical position when I select to make the wire label visible (looks terrible!):

The vertical position I always want it to stay in:

An alternative snap-to vertical position:

View All (2)

Tables should be indicators by default

Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.

It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls :)).

It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.

I suggest that the various table controls in the palettes be changed to indicators.
Their default name should just be "Table".

Enum Datatypes

View All (12)

Make Boolean Wires easier to see

I suppose this is a grey area between feature and CAR, but it is certainly a long-standing aspect of the LabVIEW editor that vexes me on a daily basis that could be improved.

The issue is that if you are dragging to select objects on the block diagram or front panel and you accidentally move the mouse cursor to the edge of the window, LabVIEW starts scrolling insanely fast in the direction of the mouse. By the time you've figured out what's happening and released the mouse, you're often 4-5 screen lenghts away the actual content of the diagram, and you must now manually scroll back to the main area. To make things worse, you're not really sure where the origin is anymore, so it takes a little blind searching to find the screen contents again. In addition, you're likely left with a selection that is not what you intended, meaning you have to start over (more carefully) from scratch.

I really don't see any reason to scroll the panel so terribly fast. At all. A slow, steady scroll, in my opinion, would always be preferable, since the fast scroll leaves the user no real control at all over what's being selected. If anyone really wants a chaotic super-fast scrolling operation to be preserved, I would perhaps accept a shift-drag option to enable this.

View All (1)

I would like to remove all broken wires that are currently visible, and not ones hidden in other cases.

I want to be able to select a case, review the broken wires, and mass delete (if applicable). Then select the next case for review.

I never use ctrl-B when working on a large application. I want to review all broken wires before deleting.. but I hate trying to double or triple-click each wire.

Something similar to this post: broken wires ...which notes that it can be accomplished with Quick Drop scripting...

Keep dropped snippet code selected

When dragging a snippet onto the block diagram, its code should remain selected so we can immediately drag (or use the arrow keys to move) it to a better location.

Currently, the new code is not selected and it is nearly impossible to separate it from the existing code, for example if a complicated snippet is dropped on an already complicated block diagram.

(Not everybody has a gigantic screen to resize the existing BD for plenty of whitespace. I also often only have a small strip of the BD showing, with the explorer window containing the "droppee" on top. Dragging the snippet to the BD invariable ends in a complete mess.)

View All (3)

Allow for Stacked Feedback Nodes

Hello all,

This is an elaboration on a prior request by RavensFan:

When AppBuilder reports a file related error, such as error 8, could someone please provide a path?

I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.

I can't probe a path wire in the AB method because the diagrams are understandably locked.

This is so frustrating. No one likes to debug by guessing and it wastes a tremendous amount of time.

Thank you with my deepest respect to the AB team.

Jim

For example:

View All (10)

View All (3)

Malleable Classes

OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.

I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster. No changes in the number of elements, no changes in methods, only the datatype of the specific data.

Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.

This one is pretty basic...and I'm guessing there is a valid reason for the way it is. Still, I wanted to throw it out there.

Right now, if you make an object, the localized name defaults to <object>.lvclass. Therefore, when you put it on the front panel, create a constant on the block diagram, etc. it will be stored with the label <object>.lvclass:

My request is that the default name be changed to the name of the class, rather than the name of the class.lvclass. The size of the icon makes it pretty clear that we're using an object, making the extension unnecessary. Either way, this is something that I change every time I make a new object and I'm curious if the other lvoop users feel the same way.

Thanks

Via this link, I learned, "If automatic tool selection is disabled, you can use the Wiring tool to select the control or indicator first and then select the terminal."

I happen to like using the automatic tool selection, so can this be an option when automatic tool selection is enabled?

E.g. if one (and only one) control/indicator is selected, clicking on a connector pane terminal will connect the control/indicator.

(I can't count the number of times I've *tried* to do this, even though it didn't work.)

-joeorbob

LabVIEW Idea Exchange

Swap Long

Probe Watch Window (Reset Index)

make Build Specification dialog not modal and resizeable

A Better "Find Missing Items" and "Find Items with No Callers" in Projects

Have All Clones included in AllVIsInMemory property

Data Aware QuickDrop Results

Add option to enforce vertical wire label position

Tables should be indicators by default

Make Trim Whitespace polymorphic and handle an array of strings

Enum Datatypes

Make Boolean Wires easier to see

Don't scroll so fast on Front Panel and Block Diagram when selecting objects

Remove ONLY broken wires in visible cases/sequences/structures

Keep dropped snippet code selected

Allow for Stacked Feedback Nodes

Application Builder File IO Errors: Reveal Which Path

Protocol Buffers (ProtoBuf) structured data serialization for use in communications protocols

Malleable Classes

Change default localized name for objects

Select Control/Indicator first when wiring to the connector pane (w/ Auto Tool)