LabVIEW Idea Exchange

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

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

 

raphschru_0-1727975484834.png

 

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

 

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

 

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

 

Regards,

Raphaël.

Hi,

 

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

 

Array_ordinary.png

 

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

 

Array_loop.png

 

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

 

Array_more.png

 

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

 

Cheers,

Steen

PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.

 

As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.

 

I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.

 

There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.

 

The solution could be as "simple" as this:

  • When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
    • Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
      • Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
    • When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.

I often want to find any cube-dropped class constants for a particular class on block diagrams in my project.  But, to the best of my knowledge, there's no easy way to do this. It'd be great if there was an option to find these when right-clicking on a class in the project:

 

class finding option.jpg

Suggest adding functionality to the event structure when handling Value Change events, so that the user can tell whether the source of that generated event was via a write to a Val(Sgnl) property node, or via a Front Panel change made by the user. 

 

This could potentially be achieved (albeit with backwards compatibility considerations) by defining an appropriate enum constant for the eventsource.ctl which available in the "Source" field of the Event Data Node (currently has "LabVIEW UI, ActiveX, User Event, and Other <>..." as the only defined constants).

 

More discussion and rationale is in this community topic:

Solved: Re: UI-Triggered Event vs. Value (Signaling) Event? - NI Community

It would be good if, after adding a custom image to the states (TRUE, FALSE, transitions etc.) or text of of a Boolean control using the Control Editor if there was an option to revert to the standard image rather than having to replace it by overwriting with a second image.

Currently the quickest way to open a typedef is right-click >> Open Type Def.

 

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
  • Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

Class data is painful, if not impossible, to properly probe when debugging LabVIEW code.

 

It doesn't need to be this way. Every other programming language I've worked with allows viewing this type of data when debugging.

 

Currently, by default, you only see probe data based on the wire's edit-time class definition, not it's actual runtime class instance. It would save me weeks (literally) a year if I could simply place a probe on a class wire and view the internal class data of the runtime class, including all levels of inheritance.

 

I realize it's not a small ask since the probe GUI would need to be dynamic (as data type/GUI elements, not just values, would need to be updated when probe is hit.)

Idea: The In Range and Coerce Include upper limit option should be selected by default.

 

1 (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Maybe it's just me, but when using the In Range and Coerce node I virtually always need to have both the Include lower limit and Include upper limit options selected. In approximately ten years of using the node I think I used a different configuration less than five times. It has entered my muscle memory that the first thing I do after dropping the In Range and Coerce node is to right-click it and select Include upper limit.


In my experience this point of view is supported by anecdotal evidence. For example, I have recently seen a large codebase that was rightfully using lots of In Range and Coerce instances. All of the nodes had been left in their default configuration (Include lower limit selected, Include upper limit unselected). However, after inspecting the code carefully I came to the conclusion that the intention was for all of the nodes to perform an inclusive comparison on both sides. This was confirmed by a conversation with the original code author. The author had simply been unaware of the true behaviour of the node (he had assumed it performs inclusive comparison on both ends) and was unaware of the right-click options!

I may want to use it 0-5% of the time.

However, I want to scroll through cases in a structure 95% of the time.

 

Making the 5% use case the default (ctrl-scroll) was a bad design choice.

Reverse it before it's ingrained.

 

(ctrl-shift-scroll is frankly awkward and imagine will become painful eventually)

 

 

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)?

 

Notes

  • 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 diagram idea: "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.

Thanks!

When working in LabVIEW in low light conditions, it would be nice to be able to have a quick way to switch to a dark mode, where the default block diagram colour would be a mid-dark-grey.

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.

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

 

 

 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
 
 align.jpg
 
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.

It would be useful if a "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style") option existed when pasting text into control and indicator labels, captions, or values.

 

Example

Screenshot 1: A GUI element (control or indicator) with a custom, non-default label and value (contents) font style.

1 (edited).png

 

 

 

 

 

 

Screenshot 2: The text "Hello World" was copied (Ctrl + C) from Notepad and pasted (Ctrl + V) in the middle of the label. The newly pasted text is inserted using the default font (Application Font, 15 pt, black). There is no option to paste using the destination font style. The developer now has to waste a few seconds reconfiguring the font. The same result is obtained whenever the text is copied from an external (non-LabVIEW) application, regardless of the application (Notepad, Microsoft Word, Excel).

2.png

 

 

 

 

 

 

 

 

Screenshot 3: The same situation occurs when pasting into a string indicator.

Combined 3 and 4.png

 

 

 

Screenshot 4: In Microsoft Word, it is possible to select the "Keep Text Only" option when pasting text. In the screenshot below, notice how "Hello World" text from the second row obeys the destination style when it is pasted into the first row. A similar functionality exists in Microsoft Excel and is named "Paste Values".

6 (edited).png

 

 

 

 

 

Notes

  • The current behaviour, where the text is pasted using the default font style, can be useful in many (maybe most) situations. I am not asking for the current behaviour to be removed. But it would be useful to have the option to select between the two behaviours.
  • When the text is copied from LabVIEW, the pasted text maintains its source formatting style. This can be useful, but again, it would be useful to be able to select "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style").

Thanks!

Listbox dividers are included in keyboard navigation of the listbox (arrow keys), without visual feedback. 

 

Dividers, which can't be selected programmatically or by mouse clicks, should be skipped during keyboard navigation.

 

See this post.

Big clusters that go beyond the limit of the FP are annoying, especially to resize them automatically and reorder the controls.

 

Here are a couple of improvements that could be made:

  • "Reorder controls in cluster..."
    • Allow user to scroll while re-ordering the controls to have access to all elements instead of having to do it in multiple time.
    • Shortcuts like Escape and Enter should respectively cancel-exit and validate-exit the reordering phase
      These are pretty standard shortcuts and already widely used within the Labview environment
  • "Autosizing"
    • Autosize to "Compact". Where instead of aligning all element vertically or horizontally only, they would be in the "most compact" (to be defined) possible configuration to simplify the access to all info in the cluster.
      For instance compacted in a square way, sorted by class (Booleans/numerics/strings etc.)
      I understand that this one might be more complex, but it would be really helpful in my opinion
      VinnyAstro_3-1705680190345.png
    • Less important (to me): In Edit Mode, in case a cluster is autosized to "none" and some items are hidden outside for whatever reason, the developer should be notified somehow. For instance the same way than for strings 
      VinnyAstro_1-1705678727875.png
    • (In the same case than above, allowing scroll bars could be interesting in some situations.)

 

-Vincent.

I wish LabVIEW had Official Container (Docker) Images.

 

With more and more users trying to use the docker in Continuous Integration, it would be 

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

 

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

 

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

 

Anyone else would support this idea or has anything to complement?