LabVIEW Idea Exchange

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.

We need a palette full of "Amish" 😉 controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.

A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.

They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.

Now, why would that be useful?

Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.

Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.

The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)

So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.

As a welcome side effect, redrawing such a FP is relatively cheap.

There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:

 For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:

We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.

I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.

Excel displays the number of selected cells.

VS Code displays the number of selected characters.

LabVIEW should display the number of selected items in the Project Explorer.

LabVIEW should also display the number of selected items on the block diagram and the front panel.

Notes

• In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
• The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
• In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
• The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
• If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

Sometimes, it would be useful to view string constants as icons to save space on the block diagram.

In a simple project, the main entry point into an application is usually easy to find:

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 

One possible implementation:

• Display tagged items as links at the top-level of the project.
• Links would be pinned to the top row
• Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
• For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
• In principle links could point to anything interesting, not just the main VI.
• Double-clicking a link should open (or navigate to?) the target item

Hi all,

What I'm asking for is an optional indication of reentrancy in the context help window.

This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.

I realize that Greg Freeman suggested something similar.  My intent here is to narrow down several ideas from that conversation down to a single suggestion.

(I hope I still didn't manage to post a duplicate. Apologies if I did.)

Thanks,

Jim

Many times a day I need to look at the full text of an error cluster's "source" string.

The workflow for this has always been awkward.

Additionally, "Explain Error" also requires some extra clicks.

What if we combined all of that functionality into the context help so that, when the user mouses over a populated error cluster with context help enabled, the user can see all the relevant information quickly?

Not so much an idea, as a wish/plead/rant:

Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.

2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right!  Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).

I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:

Graphs and charts

1. You cannot stack plots in any of the graph indicators, only in charts
2. Number of plots stacked cannot be varied at run-time
3. Annotation properties are only partially available programmatically
4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way
5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample...
6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues
7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible
visibility.

8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming

9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...

Mixed signal
1. You cannot set the group names programmatically
2. The number of plot areas is not configurable at run-time
3. You cannot assign plots to a given group programmatically
4. You cannot show the visibility checkbox of each plot etc.

And then you have the additional 2000 ideas...;-)

As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.

Would that not make everyone's day?

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.

I think that changing the justification from center to left does improve readability.

Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂