LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.

 

For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.

 

For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.

 

original.gif

 

Not a duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Array-scrollbar-quot-scrollable-quot-with-scroll-wheel/idi-p/1009220

 

[admin edit: Adding animation image at the request of the OP]

 

When programming with large applications, often times you'll have clusters carrying a lot of information.  If you hover over the cluster wire and observe Context Help, you might see something like this:

ContextHelpOriginal.PNG

 

This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:

ContextHelpNewIdea.png

 

What do you think?

 

Currently, the space constant looks very similar to an underline character, possibly causing confusion.

 

I think the icon could be made a bit more distinctive. Here are some alternatives I just made up. I would probably prefer (1) but I am open to any other suggestions. 😄

 

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

 

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

 

ReferencesIntoCaseSelectors.png

 

 

Getting a date / time time stamp is not uncommon while developing. This Type def should have a unique icon rather than the default.

JScherer_0-1664909004026.png

JScherer_1-1664909084219.png

 

 

(note: this idea is similar to this one, but different enough that I thought it warranted a new post)

 

LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:

cp.png

I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...

 

Code Formatter.PNG

 

Regards.

Quick Drop (Ctrl+Space) should support replacement (Ctrl+P) on the block diagram terminal as well as the front panel icon. The front panel icon can be selected and replaced with another .lvclass but if its block diagram terminal is selected the replace does nothing.

QDP.jpg

Hello,

 

I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).

 

But many VIs written by NI have been programmed very sloppy.

 

Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:

 

spreadsheed_file.PNG

 

Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.

 

Regards

I very commonly use the Ctrl-Drag shortcut across empty block diagram space to create new space on the diagram. When I do this, it is almost ALWAYS intended to just create space in one dimension, horizontally or vertically. If you dare try to create space in both directions at once, this invariably disrupts the arrangement of the diagram. You end up with objects that were nicely aligned being a few pixels off, or worse.

 

To create space in one direction, I have to very carefully make sure when I Ctrl-Drag that I stay exactly in a straight line, making the process tedious and error-prone. I often have to undo the operation and start over because I'm one pixel off. (One pixel is a lot in LabVIEW!)

 

It would be very very beneficial to have a similar shortcut that only operates in one direction, or to be able to specify in Tools>>Options to modify the existing behavior, because the default is never what I want.

We've all probably found ourselves writing various forms of this:

TurboPhil_0-1621002015826.png

It would be great if there was a malleable version of the "Traverse For G Objects" function that shipped with LabVIEW to save a few headaches. Rather than passing in a string for the class name, and then adding a downstream ToMoreSpecific operation, it could accept the refnum constant (in the above example, the "Control" class ref) and return an array already cast to that class.

 

On bigger projects, when creating a new class, I find it time-consuming to track down the parent class I'd like to inherit from.

 

It'd save me some pain if there was some kind of filter and/or search option for this on the New Class GUI:

 

_carl_0-1614272545841.png

Other thoughts on this:

- While the tree structure is useful, I usually know the name of the parent class I want to inherit from, but I don't necessarily know the full inheritance of it, meaning the tree structure isn't the most efficient way to find it.  (Even alphabetical by class name would be faster in these cases).

- I'd find the tree structure here easier to follow if the lines were visible.

Let's say I have a ring control filled with lots of of items, but I decide that it would be better for the user if he could see all the options without having to pull down the ring. I right-click on the ring control, choose replace and select a Listbox. Now I have an empty listbox though, and I have to recreate the list. Most of the times when I do this I want the items I had in the ring control to transfer to the new control, like this:


replace with content carried over.png

 

The transfer of items should work both ways, and apply to similar replacements, like a change from ring to enum e.g.

It would be nice to have a way to choose whether to keep the items or not of course (key control while doing the replacement or a dialog asking if you want to keep the items), instead of having to delete the items afterwards if you did not want them, but I am not sure it would be needed that often. I would be perfectly happy for the default to just keep the items.

PS. Writing a quick drop shortcut plugin is one existing way of getting this functionality without having to wait for NI to implement it in the IDE...Perhaps someone has already done that (?). This request is for it to become (or be a part of) the default behavior though.

One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.

 

Still don't get it?

 

This is how big I want my SubVI window to be:

2014-10-01_13-24-54.jpg

 

Problems with the above:

  • A lot of the toolbar buttons and menu options are completely inaccessible
  • I'm sure it was for good reason (probably some other icons that appear there), but there's also a load of empty space to the left of the run button which would allow me to fit more of the toolbar on screen

To be able to access the entire toolbar, the windows has to be at least one of the following wide:

2014-10-01_13-25-13.jpg

 

 

Why is this a problem?

 

  • Normally my front panel windows are nicely sized according to the controls and indicators on the front panel (e.g. controls top left, indicators top right, error clusters bottom), for most SubVIs this usually means that the window is thinner than the minimum width to show all of the toolbar options.
  • If you have a fixed size UI panel (e.g. for dialogues) - if you want to align / space objects on the panel you have to make it larger, do the scaling and then resize back to the original size which isn't ideal (possibility for not resizing to the original size correctly)
  • Similar to the above but if you have a UI where you have fit/scale to pane you might want the initial size of the UI to be smaller than the minimum width

Existing workarounds:

 

  • Just before submitting this idea I realised you can shrink the 'search' bar from the toolbar to make it slightly better2014-10-01_13-25-38.jpg
  • Use the OpenG (?) VI for 'fit to largest decoration - this is OK for some UIs but not really suitable for the SubVI case above

Proposed solution:

Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.

 

MS Paint skills (icon lifted from Chrome's bookmarks bar):

2014-10-01_13-24-54_fixed.jpg

 

As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:

2014-10-01_13-44-07.jpg

 

Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.

Add another option to the Search Scope to Ignore VIs in user.lib

That's it!!  😁

Search Scope - user.libSearch Scope - user.lib

This is a follow on to this idea. After terminals are wired to growable nodes. Make it easier to move and reorder the terminals. The switcharoo tool exists if there are only two terminals but it is difficult if there are more. 

I suggest making it easier with a keyboard/mouse combination or mouse long hold or something like that, to select a terminal. Then let the user drag it to another terminal and drop it. If that terminal is wired swap the selected wire and the one dropped over. If not wired, move the wire connection to the terminal dropped over. 

While writing/debugging applications that make heavy use of reentrancy it is not uncommon for a reentrant VI to be left open after the rest of the application has shut down.  This leaves VIs, Classes, LVLIBs locked in the project and your only recourse is to hunt down the offending reentrant item or close the project and reopen it. 

jon_mcbee_0-1616609690472.png

 

It would be valuable to be able to see the running clones in the list of reentrant items found by navigating to View>>Browse Relationships>>Reentrant Items, maybe denoted by a *, like this below:

 
 

Having that would easily allow me to open the running clones and close them out manually so I can continue debugging.

As shown by below RG code, the Select function should be redesigned in order to align the s input with the output vertically. Currently, the input is too low.

 

Select.png

Using 2023 for the first time (skipped 2021 and 2022)

 

QuickDrop used to be quick.

It was very convenient.

 

Now it takes a second to load.

 

That's pretty inconvenient if you're trying to... do much of anything.

 

Best example: If you're trying to remove code (Quickdrop's Control-R), now instead of quickly removing the selected code, you get to deal with accidentally RUNNING your VI (Menu's Control-R)

 

Please make it Quick again