I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.
BD-Only VIs would be beneficial because:
They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
They would reduce the developer workload, thus making developers faster.
They would reduce the surface-area of the codebase.
They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.
BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?
I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagramidea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.
I don't know how many times I've built an application or packed library during my 25+ years using LabVIEW. What still annoys me extremely much is when the AppBuilder gets a tiny error, like "wasn't able to copy this file" (always at the END of the job), or something else having no effect on the (already built and completed) application or PPL itself. Still AppBuilder deletes the whole build, sometimes 30+ minutes time wasted, and simply tells you the build "FAILED".
My suggestion is: Make AppBuilder just a tad smarter and don't delete the EXE or PPL! Just let the developer know what file(s) to copy manually, or what post action didn't work!
When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.
When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.
The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.
Often when I want to look at the structure of a complex data type containing nested typedefs, I find the data type description in the Context Help quite heavy/verbose.
For example, could you tell at first glance how many levels of hierarchy there are in this data structure ?
Well, actually there are 5 levels (including the root cluster), but this is obfuscated by the unnecessary levels added by typedefs.
The description could be much more concise:
Here is an alternative that keeps the typedef type descriptions and appends them after the typedef name. However I'm not sure about this one because it could create description texts that are too long to be displayed in a single line:
Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:
It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).
Show the Context Help for packed project library VI terminals. Without it, development suffers. For example, a wire conflict occurs but the nature of the source or sink type is not available for inspection.
The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.
90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:
Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
You could more easily get to the BD of VIs running in a subpanel.
It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.
Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).
This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.
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.
I just realized that when creating an interface you cannot create property node folders.
You can see from the pictures below that option is missing from interfaces.
You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.
Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.
Here is a use case, which I think is fairly common - it happens to me a lot:
I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).
The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.
Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.
Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?
It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?
It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.
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?
Quick Drop (Ctrl+Space) is often used to work with a selected VI (e.g. Ctrl+P replacement). The Quick Drop dialog window opens with blank text box. Default that text box to the VI name if one is selected when Quick Drop is opened. That text should be pre-selected so that typing replaces it (no extra keystrokes for backward compatibility). Furthermore, it would be extra nice if the selected VI was automatically highlighted in the list.
Currently if you draw a diagram disable structure around a section of code any wire coming out of it will be set to "Use Default if Unwired". This is almost never the desired behavior, and can easily lead to bugs if people forget to connect wires through on the Enabled case. The VI should be broken until the developer makes any necessary changes in the Enabled case.
One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.
There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.
The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.
When debugging it's common to place a series of probes on a wire that goes into an out-of multiple sequential subVIs (a "rail" wire).
For example, in the screenshot below, we might want to place four consecutive probes, on each of four consecutive error wire segments.
Currently this requires four right-click gestures.
It would be useful to have a "Probe Chain" menu item (not sure if this is the best name, please suggest better ones) just beneath "Probe" or beneath "Custom Probe", or perhaps beneath "Generic Probe" in the Custom Probe sub-menu.
When clicked, the "Probe Chain" would apply a probe to each wire segment in a sequential or consecutive set of wire segments. This would result in the same set of four probes shown in the first screenshot. It would save a few right-click gestures.
Another typical example would be when probing an object or cluster wire.
I'd be happy if the propagation of the probes occurs only in the downstream direction. What I mean is: if the user right-clicks on the wire segment between SubVI B and SubVI C (screenshot above), then probes 6, 7, and 8 would be created (using the numbering in the screenshot above), but probe 5 wouldn't be created because it is "behind" or upstream of the segment where the action was triggered from. I'd be happy if the propagation worked in both directions, but I suspect that the implementation would be slightly simpler for just the downstream direction.
In the first screenshot above, it would be ideal if the tool would create probe 4. But I'd be happy if the tool would omit creating that probe on the grounds that that wire segment is bifurcated, assuming that dealing with bifurcated wires would make the implementation more difficult.
Perhaps pseudocode for determining if wire segments are sequential or consecutive (i.e. if they form a "rail") is: if a node takes as input a single wire of a given data type, and outputs a single wire of that same data type, then consider the two wire segments to be part of the same "rail". I wonder if the Quick Drop Ctrl+W tool already implements a similar algorithm, and whether parts of that algorithm could be reused.
Currently if you create a new VI for override, whether or not the terminals are displayed as icons is determined by the VI being overridden (e.g. overriding Actor Core.vi will always give you terminals as icons). Instead, I propose that it be determined by the user's preference in the Tools--> Options menu. If we've said we don't want terminal icons, shouldn't all newly created VIs respect that?
Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.