From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

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.

 

second.pngfirst.png

 

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.

Often, I have wires already on a block diagram and I want to add a new structure (case, flat sequence, etc.) that utilizes those wires internal to the structure or in some cases passes them completely through the structure. For example, consider needing to implement data flow for a node that has no error input and output, such as when using the Wait (ms) function. To implement data flow when using this function, I might place it in a flat sequence with a single frame and pass an error wire through it as shown:

Ryan_Wright__1-1708013874803.png

If the wire already exists and you try to put a new structure over the top of it (using the same example referenced above), you get the following behavior:

Ryan_Wright__2-1708013992633.png

It would be really nice if LabVIEW would automatically pass the wire through the structure or at least wire up to the left border when doing this as shown in the following pictures:

Ryan_Wright__3-1708014077542.png

Ryan_Wright__4-1708014170821.png

The automatic wiring behavior of whether to pass the wire completely through the new structure or to only wire to the left border could be evaluated on a case-by-case basis for each structure (For Loop, While Loop, Case Structure, Event Structure, Flat Sequence, Diagram Disable Structure, Conditional Disable Structure, etc.).

There should be a Browse button on the right click menu for front panel items as it is on the block diagram right click menu.

Quiztus2_0-1707817399604.png

Make the search in Browse traverse the displayed property tree instead of the type specialization.

Otherwise you won't find Increment when searching the graph's properties:

Quiztus2_4-1707817683201.png

 

Just display the hierarchy with the results like:
X Scale::Range::Increment

Y Scale::Range::Increment

 

 

 

 

 

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

 

rearrange-subdiagram.png

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

 

rearrange-subdiagram-labels.png

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

 

rearrange-subdiagram-labels-preview.png

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?

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?

 

ContextHelpErrors.png

Not every bundle is linked to a Typedef. It would be very useful to automatically inherit the names of previously named wires into bundles.

Showing the Current and Proposed behavior for name inheritance in the bundle functionShowing the Current and Proposed behavior for name inheritance in the bundle function

As part of everyday class development, I often want to track down everywhere where certain class data is being used. Would be convenient if there was a shortcut for doing this...perhaps something like:

 

_carl_1-1678141878195.png

 

 

On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible. 

srlm_0-1685481071737.png

 

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

 

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

 

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

 

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

 

Essentially, what I would like is a Type Specialization Structure that works backwards.

 

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

 

Simple example of SelectSimple example of Select

 

 

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.

 

If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation

 

I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.

I mean, OpenGL is cross platform, right?  Let's bring graphics performance at least into this century.

The current register event callback node is allowing an easy way to handle ActiveX and .Net Framework events. This node is also very similar in appearance to the property nodes, yet it does not have an insert (Add Element) or remove (Remove Element) function available in the context menu. Since the property nodes, and also the named (un)bundle nodes are having this implemented, I think it would be nice to have these easy to access functions instead or having to grow the node, change all the elements below the one that we want to insert and rewire everything.

One downside of this idea is, that it will throw the wires a little further away than the upper mentioned named (un)bundle and property nodes do, since it is a 3 terminal height element.

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

 

Before.png

Start wiring the new error, then click on the merge error node.

During.png

LabVIEW expands and connects the error wire

After.png

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

 

 

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

Bonus.png

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

 

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

simple.png

 

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

complex.png

 

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:

links.png

  • 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

 

Current behavior:

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.

 

Desired behavior:

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.

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 ?

 

raphschru_2-1700832707643.png

 

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:

 

raphschru_3-1700833121443.png

 

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:

 

raphschru_4-1700834723096.png

 

Also for the configuration, it could be an option in "Options > Environment" and/or a button in the Context Help:

 

raphschru_7-1700835928603.png

 

What are your thoughts ?

 

Raphaël.

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

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

 

2020-12-11_12-28-19.png

 

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

 

 

2020-12-11_12-34-49.png

It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down.  Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI.  The tool should just work.  "Ctrl+." doesn't always work.  You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.