LabVIEW Idea Exchange

As mentioned in this post, and elsewhere, it is very helpful on the forums to (1) post images and (2) post code that is usable by the masses (typically 8.6+).  Snippets are a useful way to post both images and code (for 9+ officially and earlier with a few tricks like the Code Capture Tool).  One downside is that if you are working in LV10 your snippet is not usable in earlier versions.  It would be nice to be able to Create a Snippet for a previous version in one operation.

I do this myself, for example:

Makes life easier for both the posters and the responders on the forums.

Feedback nodes can reside entirely inside one case of a case structure. This simplifies coding if feedback operations are limited to one single case. Unfortunately, there is no easy way to retain the output once the loop has finished if the last iteration executes one of the other cases. As a result, we might see local variables or even indicators inside the case containing the feedback node, defeating the "in place" purpose. For a "wired" solution, we need to place the feedback node outside the case and wire across all other cases (image top).

I propose an output terminal that sits on the output edge of a loop and contains the contents of the feedback node at the time the loop finishes. Typically that would be the edge of the same loop that contains the initializer terminal (image bottom), but it should also be available for globally initialized feedback nodes and on other loop boundaries surrounding the feedback node (selectable).

I am sure this idea needs to be worked out in more detail, so this is just an initial concept. 😄

As a service to trivia buffs everywhere, as well as helping us help people with different LV vintages, I would really appreciate it if the LV help detailed the required version for the various functions and VIs in the palettes.  A simple indication in the 'Requires' field would suffice.  The more the better, but at least start with recent/new additions and work back.  "When was that added?" is a quite common theme.

The current implementation of script nodes (formula, mathscript, etc.) is a bit unwieldy. We have to find a delicate balance between node size and content. (too small and we need to constantly scroll the text code. Too big and it is difficult to wire around it and fit it into the rest of the g code.)

My suggestion is that script nodes on the diagram look just like e.g. call library nodes (or possibly express VIs). Double-clicking them would open a separate editor window that floats above the code. Near the top we have a growable area where we can define the connector names, inputs and outputs  (variable name, datatype, etc) and below we have a nice code editor window similar to the current mathscript node, just comfortably big (e.g. like notepad)! At the bottom there could even be extra tools, e.g. like import from text file, save to text file, etc.

Typically the node would be collapsed into an icon but the script window can be left open during editing and debugging.

This is one case where breaking out of the confines of the 2D diagram would be helpful. The current formula nodes just don't really belong directly on a diagram. Nobody want to compose and edit text in an area the size of an old cellphone screen.

This is just a very rough Idea. The details would need to be worked out further....

My front panels are typically large tab controls so most of the FP design and editing takes place on tabs.

In this scenario we lose significant usability, for example:

• We cannot double click on empty space to create a free label
• We cannot see the alignment grid.
• ...

When right click on a cluster and selecting "Reorder controls in cluster..." the bloody control indexes hide the labels of the controls in the cluster, rendering it difficult to select which ones should be in which order.  How does the programmer distinguish between one or another control??!!!???  :mad:

Hopefully the image below is worth 1000 words.  And yes, I did resize the cluster in the hope that the re-order index would go further to the right of the control, but it didn't.

This is something that needs to be fixed.  It should actually be considered a bug rather than a product enhancement. 

When dealing with a small cluster, it might be okay... but when dealing with clusters having over 200 controls, setting the proper order in a royal pain!

One of the quickest (and easiest to forget) methods to improve performance of your VI is to disable debugging.  It requires a trip down the VI properties to get there, however.  I propose adding a button on the BD alongside the other debugging buttons to Disable and Enable Debugging.  

This LV typedef for the Waveform Graph property Cursor List is missing Line Width and Line Style! This is probably a solution to the mystery behind another post Show Attributes Selections I made earlier today. In order to completely define our Cursor List properly with one Property Node, those two elements must be part of this public typedef.

HABF?

An acronym for one of my favorite Spolskyisms. Great article, read it.

Background

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

Problems with Current Issue Tracking Platform

"Platform" is a generous term for the current reporting and tracking process:

1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into.  The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

I want to see an analogue for Issue Tracking.

Proposed Solution

A web-based platform with the following capabilities:

1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
2. Allow embedded video screen captures (such as Jing)
3. Allow uploaded files that demonstrate reproduceable issues
4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
7. The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
10. An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
11. Same username and logon as the Forums
12. Bonus: Visible download links to patches and other bug-related minutiae

Additional Thoughts

• I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
• I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
• Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

(Picture first spotted on Breakpoint)

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

As described here, the Event Structure has a few interface issues. One of which is that the "Rearrange Case" Dialog window is not resizable, and the "Complete selector string" has no scrollbar:

If you have dozens of cases, some of which may contain a dozen different events, this is a nightmare to use.

Don't get me started on the way you can rearrange cases only by dragging and dropping one at a time (ever heard of alphabetical sorting for instance?)!

Thanks for reading.

Hi,

Often you see in code one large text box for comments and labels on each section of code for which the comment applies.

How about a small speach bubble type icon which can be placed on the block diagram, which when clicked/hovered on will pop up comments either in its own window or in the context help window.  This could be linked into the new requirements tracking tools as well.

Craig

It would be great to be able to have multiple "Search Results" windows open at the same time. 

A few typical use cases:

• Some searches can take a LONG time, especially where dynamic dispatch is involved. It is always painful to have to close a big search just to do a small one.
• Sometimes I need to search through instances of two or more distinct items for comparison purposes. 
• Searching is a handy way to navigate. Leaving a search window open is like keeping a bookmark to a useful part of the code.

The only issue I see is that keyboard shortcuts (e.g. "Ctrl + G") would need to be restricted to only one of the windows. It seems reasonable that keyboard navigation could simply apply to the topmost search results window.

Every time I need to open up several VI's at the same time, my Windows Taskbar becomes full of open windows and it gets hard to wade through everything.  Part of the reason for this is that every time a VI is opened, two windows have to be opened to view the block diagram (both the front panel and the block diagram).  I would like to see a fix that allows me to just have several block diagrams open at one time without their front panels, making it easier to deal with the numerous open windows I get sometimes.