LabVIEW Idea Exchange

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

V1.0 of TOML was recently released : https://github.com/toml-lang/toml/wiki

There is an MIT Licensed open source project here : https://github.com/erdosmiller/lv-toml

 

It's a nice starting point, but :

- it's not complete

- it's based of v0.4 of TOML

- it not maintained as stated here : https://lavag.org/topic/21972-anyone-using-toml-files/?do=findComment&comment=135193

- it's not native

It's useful that we can open the Error List window via the Ctrl + L shortcut.

 

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.

 

I would be happy with any key combinations chosen for this purpose.

 

Thanks

After fighting an increasingly slow IDE for a while I found the reason editing my libraries and classes was slow: Lengthy and large mutation history.  I'd like to see an easy option to clear that history so I'm not burdened with the edit-time slowness when I don't have to be:

DelMut.png

If I was smart with right-click-frameworky stuff I guess I could make it work myself, but for any so inclined:

DelMutCode.png

Dear LabVIEW Team,

I hope this message reaches you in high spirits and with a cup of tea in hand, because I am about to share a groundbreaking idea with you.

After years of fascinating work with LabVIEW, I would like to express my sincere admiration for the breathtaking number of windows that make your development environment so unique. While other programming environments like Visual Studio try to structure the development process in a boring way, you clearly rely on the "more is more" principle.

It is simply fascinating to see how each VI always has two independent windows. It makes me feel like I'm exploring a virtual windowscape - a journey into the unknown where each window is an adventure in itself. I can't remember the last time I had this much fun developing.

But why settle for just a few windows when we could take inefficiency to a whole new level? So I propose: Let's keep increasing the number of windows! Why not give every single structure in the code its own window? That would really be the pinnacle of chaos efficiency.

 

I imagine it like this: When I create a loop, a new window opens in which I can program the code for the loop. For each case of a case structure - another window. The possibilities are endless! An endless labyrinth of windows that turns my screen into a colorful kaleidoscope. That would be the pinnacle of innovation, wouldn't it?

I hope my ironic enthusiasm for the distinctive LabVIEW window concept has been well received. I am certainly available to discuss this idea further and am willing to contribute to the creation of an even more chaotic, but undoubtedly entertaining, development environment.

With sarcastic regards,

An enthusiastically chaotic LabVIEW developer

 


Sehr geehrtes LabVIEW-Team,

 

ich hoffe, diese Nachricht erreicht Sie in bester Laune und mit einer Tasse Tee in der Hand, denn ich stehe kurz davor, eine bahnbrechende Idee mit Ihnen zu teilen.

 

Nach Jahren der faszinierenden Arbeit mit LabVIEW, möchte ich Ihnen meine aufrichtige Bewunderung für die atemberaubende Anzahl von Fenstern aussprechen, die Ihre Entwicklungsumgebung so einzigartig machen. Während andere Programmierumgebungen wie Visual Studio auf langweilige Weise versuchen, den Entwicklungsprozess zu strukturieren, setzen Sie eindeutig auf das Prinzip "Mehr ist mehr".

 

Es ist einfach faszinierend zu sehen, wie jedes VI immer zwei unabhängige Fenster hat. Das gibt mir das Gefühl, als würde ich eine virtuelle Fensterlandschaft erkunden – eine Reise ins Ungewisse, wo jedes Fenster ein Abenteuer für sich ist. Ich kann mich nicht erinnern, wann ich das letzte Mal so viel Spaß beim Entwickeln hatte.

 

Aber warum sich mit nur ein paar Fenstern begnügen, wenn wir die Ineffizienz auf ein völlig neues Level heben könnten? Daher schlage ich vor: Lasst uns die Anzahl der Fenster weiter erhöhen! Warum nicht jeder einzelnen Struktur im Code sein eigenes Fenster zuweisen? Das wäre wirklich die Krönung der Chaos-Effizienz.

 

Ich stelle mir das so vor: Wenn ich eine Schleife erstelle, öffnet sich ein neues Fenster, in der ich den Code für die Schleife programmieren kann. Für jeden Case einer Case-Struktur – ein weiteres Fenster. Die Möglichkeiten sind endlos! Ein endloses Labyrinth von Fenstern, das meinen Bildschirm in ein kunterbuntes Kaleidoskop verwandelt. Das wäre doch der Gipfel der Innovation, oder?

 

Ich hoffe, meine ironische Begeisterung für das unverwechselbare LabVIEW-Fensterkonzept ist angekommen. Ich stehe Ihnen selbstverständlich zur Verfügung, um diese Idee weiter zu diskutieren und bin bereit, meinen Beitrag zur Erschaffung einer noch chaotischeren, aber zweifellos unterhaltsamen Entwicklungsumgebung zu leisten.

 

Mit sarkastischen Grüßen,

 

Ein begeistert chaotischer LabVIEW-Entwickler

 

                     this time, I hope this idea was not already proposed! Smiley Frustrated

 

 

original6.png

 


When a user clicks and drags a slider - hundreds of value change events are generated for your code to handle.

 

Most of the time the user experience you want is just to use the value when the user has stopped dragging the slider. Similar to a text input field where you can select to have the value update only once the user has finished typing instead of all the intermediate values.

 

My proposal is to change the slider events to support this use case. I'm inclined to leave the exact solution open - as long as NI can support this use case.

 

There is another idea to add an ended event which would allow for this: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-a-quot-User-Control-Ended-quot-Event/idi-p/1075504?profile.language=en but I created this post to be more specific.

 

You can find a number of attempts if you search the forums for "slider too many update events" such as 

 

If you follow this through there are always compromises in every solution for getting this behaviour.

Here is a simple idea. The picture says it all. Clicking on the Idea Exchange link in the getting started window brings you right here!

 

getting started.PNG

 

[Edit: Nothing really confidential in the recent files but...]

I would prefer to have a feature added to space objects horizontaly and verticaly by value. It would be very helpful for arranging objects in block diagram and front panel. br ws.

 

LabVIEW Exchange.png

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.

 

During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).

 

To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.

 

I wanted to use a property node in an application today. I happened to have the Help context up and it showed "Run-Time Engine: No". But I could easily have missed that and not discovered the issue until much later, after building a lot of code and wasting time.

 

If the node had an obvious indication as soon as you put it on the block diagram - for example, a different color - that would help a lot and potentially save a lot of headache.

Hi,

 

After we have gotten several different new tunnel modes, it takes quite a lot of context menu exercise to change tunnel mode on structures:

 

Tunnel_Context_Menu.png

 

I propose a shortcut where we can click directly on the tunnel to toggle between valid modes:

 

Tunnel_Easy_Mode_Toggle.png

 

I say valid modes as not all modes are valid for all tunnel data types, for instance the "Concatenating" mode isn't allowed for scalars, but is still selectable in the context menu resulting in a broken scalar wire leading to the concatenating tunnel - the toggle should perhaps skip such an invalid setting? Or maybe not, in case you're preparing to change data type and just want to toggle the tunnel first, I don't know.

 

Tunnels on different structures have different modes. On case and event structures the modes you could toggle between would be 'Use Default If Unwired' on/off for instance.

 

Am I the only one feeling there's a long way into the tunnel mode menu now?

 

Cheers,

Steen

reference case structure.jpg

 

 

I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references.  It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).

I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.

 

The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).

Could be very nice for scripting.

 

 

 

 

 

Almost every time I work on a new test system and start documenting, I can't tell which drivers, add-ons... the code depends on.

The documentation (design description) should at a minimum tell a new developer what drivers, add-ons... must be installed to have the code executable on a development machine.

I've issued a support request on this, but the support team told me that there are no such funtionality in LabVIEW. The Dependencies folder in the project gives you some indications. VI Hierarchy and VI Analyzer also give some indications. The only way to sort this out is to install LabVIEW stripped from all extras and then install one driver/add-on... at a time until your code gets executable.

 

My suggestion is that the LabVIEW development environment is equipped with a functionality where the drivers, add-ons... required for your code can be shown.

The red star which indicates that a Reference Control is strictly typed gets partially or completely hidden by many of the graphics as shown in the some of the controls on the top row of the picture below. I suggest we either send the star to the front of the graphic, or as Altenbach suggested in my thread that started the discussion, to the top of the graphic as shown.

 

StrictStars.png

LabVIEW's HTTP Request client currently does not support the PATCH method. This method is becoming increasingly more popular within RESTful API's and has been an officially recognized verb since 2010 (RFC 5789). It should be fairly simple to integrate, since LabVIEW runs cURL under the hood and cURL implements it with curl --request PATCH

 

Format into text is very useful but can become hard to edit when it has a lot of inputs. I propose, instead of one huge format string, that the programmer be allowed to put the required format next to the corresponding input. Also, the user should be allowed to enter constant strings, e.g.. \n, \t, or "Comment", and have the corresponding input field automatically grayed out.

 

FORMAT INTO TEXT IDEA

Oftentimes, I'll use a probe simply to see if code has executed, waiting for the probe value to change from "Not Executed" to the value on the wire once it's first executed. Having a "Reinitialize" or "Reset to 'Not Executed' " context menu item would make debugging iterations faster.

 

ReinitializeProbe.png

The static VI Reference has the ability to be made strict. A strict and static VI reference shows the icon of the target VI (static part) and a small red star (strict part). This allows a strict, static VI reference to be wired directly into a CBR node.

StrictStaticVIRef.png

However, the new async CBR feature does not work with strict, static VI references because it also requires option 0x80 or 0x100 to be wired into the Open VI Reference.

 

There should be a way to specify an async call inside a strict, static VI reference. That way, an async call can be made by way of a reference returned by a strict, static VI ref and not just with an Open VI Ref.

The Problem:

When storing many builds of installers, currently there is no easy way to find out the version number of the exe that the installer installs.

 

In the past I had tried to work around this by programmatically setting 'Installer Product Version' to the same as the exe in my build script. Installer Product version can be found in the installer's nidist.id file under [Volume Id]>DistributionVersion, and the setup.ini file under [Distribution]>Version. This works nicely until you want the build number, or major/minor exceeds 255: 'Installer Product Version' is stored in the format major.minor.fix and the max values are 255.255.65535 i.e. u8.u8.u16. This is a limitation of MSI installers. See:

Version Information Page (Installer Properties Dialog Box) - LabVIEW 2018 Help - National Instruments
ProductVersion property - Win32 apps | Microsoft Docs

 

 

Executables have Version Numbers in the format major.minor.fix.build, with max values 65535,65535,65535,65535 i.e. u16.u16.u16.u16


I would expect the installer's setup.exe's File version (under Properties>Details) to be settable as major.minor.fix.build, but this is not the case. File Version seems the most appropriate as it is 4 digits and this is used in built exe's. I would like this to be settable via property nodes (in the same way as .exe's) as it does not have the u8 limitation and does not omit the build number. Currently property nodes do not affect it. If numbers larger than the u8/u16 limits are set via property nodes, they max out in nidist.id and setup.ini. Another acceptable workaround would be to include another key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes.

 

 

Proposed Solution:

Property nodes affect the installer's Setup.exe version number under properties, with max values of u16.

leahmedwards_0-1644830421412.png

 

Or there is a new key/value pair in nidist.id or setup.ini that allows u16 major.minor.fix.build to be set via property nodes, in addition to the existing key/value pairs that have some u8 max values and omit build number.

 

Perhaps this will no longer be an issue if NI moves away from MSI installers...

Format Into String can become very complicated when you have multiple inputs. I think implementing it in a way similar to the Formula Node could make it much better.

Ideally,

  1. naming of the inputs should be allowed
  2. the input fields in the string should be color highlighted
  3. when hovering or clicking over any of the input or the format string fields, the matching ones should be highlighted in bold or with different background for example.

FJR0_0-1697721252785.png

As a side note, the Formula Node itself could also benefit from the same color and hover highlighting.