I find the process of initializing Maps in LabVIEW to be unintuitive and inconsistent with the initialization process for other similar concepts (such as, say, arrays). After some initial trial and error, the process I've settled into for creating maps is to drop a map constant, and then to drag and drop the appropriate data types onto it for my key and value. I first looked for an Initialize Map VI (which doesn't exist) and then tried to create the constant by wiring up appropriate types to an "Insert Into Map" and creating the constant from there -- but this doesn't work as expected because the terminals don't update appropriately.
What drove me to coming to the forum today though, was that in creating a malleable VI with a map inside of it, I found a breaking point for the "drop constant and drag values into it" approach. Since the map data types need to be dynamic to support malleable VIs, I've had to get creative to get around that...
Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.
What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.
Now every Joe on the planet updates their Windows 10 with the latest Office 10..
What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"
When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.
NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.
The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.
If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.
I have been working with LV since Dr. G was roaming the halls on LV 3...
This is the FIRST TIME Report Writer has gotten "sick".
This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.
Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.
My number 831-455-0418
Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10
Make 'Get LabVIEW Class Parent And Member VI Information.vi' work on the type of data on the wire and not only the type of the wire to make it possible to use it together with 'Get LV Class Default Value.vi' so info on classes from source distributions and PPLs can be extracted.
This would make such classes easily available for use in dynamic factory pattern designs.
The current implementation of 'Get LabVIEW Class Parent And Member VI Information.vi' cannot give me any info I don't already have access to in development. The only classes it will work on are the ones already loaded/known as it returns result based on the type of wire instead of the type of the class data on the wire. This limitation (as I see it) greatly decreases the use of the VI.
The same can be said for the 'Get LabVIEW Class Information.vi' as can be seen here:
As can be seen the wire needs to, at some point, be present and wired into a 'To Variant' for the VIs to return correct results. This will sadly never be the case for any dynamically loaded class from a PPL or a source distribution!
I use classes widely for extending functionality and often I want to have a dropdown or a list or a tree of classes of a specific hierarchy or interface maybe even filtering the ones that implement a certain dynamic dispatch vi. I have been using config files created from the development environment for this, as a workaround, but in 2020 I wanted to get a live integration of new classes by scanning for new classes, loading them and registering their data. (In practice what I'm doing today is that I copy a PPL containing classes into a common PPL folder and register the classes and their heirarchy/members in a config file. This makes the new classes available to the application without a need for rebuilding it.)
An example could be a UI element that allows the user to launch an actor from a ring control. So what types of actors are available? The application cannot know this. Any actor that comes from a PPL or a source distribution will be unknown so the application cannot properly populate the ring control. It is possible to find all classes by looking at the extension, but not what hierarchy they belong to. In 2020 this could have been done using the following code (if it worked as I suggest):
Sadly this will never return anything useful as it can only look at the LabVIEW Object wire.
I guess all the other data type VIs work in the same way, however that has never been an issue as the data types could only be mixed when they were variants already and there isn't (to my knowledge) a load data type by name/enum VI.
In my dream scenario I wouldn't even have to load the class into memory to acquire the info. A path based version of 'Get LabVIEW Class Parent And Member VI Information.vi' would be perfect for use with dynamic factory patterns. This is however a minor issue as the data can be stored between executions instead, but one can dream right :).
Sorry that my ideas/requests always end up being walls of text...
Annotate palette items with dynamically generated keyboard shortcut characters. The keyboard shortcuts should be such that users don't have to use two hands to type them out. Typing out the shortcut will close the palette and put the palette item on mouse cursor. If the shortcut is on a palette folder, the palette will remain open and show content of the folder.
This is a great symbiosis between mouse and keyboard and will increase user's coding speed by reducing mouse travel.
There should be a couple of options for opening the palette via keyboard shortcuts for a complete experience-
Shortcut to open main palette. Similar to right click on blank space.
Shortcut to open recently or most used items palette.
Shortcut to open parent palette of node under cursor (or last node dropped).
Shortcut to open palette related to datatype of wire under cursor.
Here is a visualization of how the annotations might look like-
Note that all the shortcut characters are on left side of the keyboard, and could be typed one handed operation by a touch typist. It will be easy to configure the tool for left-handed people and concentrate the keys on right side of the keyboard. Also, the letters have been selected in a way that the two keys are on separate fingers for faster typing.
Comparing to quick drop feature-
Quick drop requires user to recall from memory. User has to either remember the short name or the full name of the item. With this idea, the shortcuts are right in front of the user.
Characters of full name of the item on quick drop can go all over the keyboard. User either has to move one hand around which will require looking at the keyboard or move the mouse hand to keyboard. With this idea, it will be easy to control the shortcuts to be on one side of the keyboard.
Note: Short name of items in quick drop are concentrated on left side of keyboard, catering only to right-handed use. Not sure how easily the short names can be configured for left-handed use.
Overall this idea supplements quick drop. It speeds up a few happy paths.
Figma. It is a website design tool and has a tiny palette with rectangle, circle, line, text, etc. It has keyboard shortcut for each of the palette item – R for rectangle, L for line, T for text, and so on. E.g. typing R brings the rectangle on mouse cursor. It has a small palette so remembering the shortcuts is easy. This idea cannot be directly ported to LabVIEW because of the billions of palette items.
Vimium C Chrome extension. This extension enables experience of vim editor in browser. One of the features it has is annotating links with dynamically generated keyboard shortcuts. Typing out the shortcut keys takes you to the link.
The idea is the same as Separate Compiled Code From Source File. When using external source code control (SCC) software like git, the user may want to track only the source code content changes. However, when every time saving the VI, the VI Revision History will be incremented. This reflects the change in VI attribute / VI properties, even though the other contents are the same.
This makes the commit log like git hard to trace the real change in the source code content from a high level. When using the compare VI tool, this attribute change will be one of the highlighted difference, which is quite distracting & confusing such as below:
I suggest this option can be disabled at the level of VI, project, or environment like the option of Seperate Compiled Code from VI. Hope it would be accepted 🙂
Since development of Labview NXG will be discontinued this year, a back conversion tool would be extremely helpful in order to move NXG-projects back to the original Labview. I think NI has the responsibility to help the programmers who followed their call to the "new and future version of Labview" which is now discontinued.
This works great, but during development the page obviously does not change when changing the enum. Either you right-click the border of the tab control and "Go To Page" or you display the Page Labels Display (and programmatically hide it) or something along these lines.
But why not make the tab control's Page Labels Display an enum in the first place? Being able to customize it would be great, but just making it an enum would be really helpful.
We get the look we want
We avoid having the extra event to change page during runtime
I use a lot of user events and often define the user event references in a typedef cluster before actually writing the create/generate/destroy code. It would be really helpful if the Create User Event primitive would change its input datatype based on the output (i.e back propagate the datatype), much like the Variant To Data primitive.
If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.
Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂
I have several versions of LV permanently installed in order to maintain old code, going back several years. This is because most often it is not possible - or even not allowed - to upgrade RTE's and/or Device Drivers at target PC's working at factory shopfloors.
I often end up opening projects with a newer LV version without being aware of it and it happens to inadvertently save VI's with that version and - even if most often I "hit" only one VI - that is enough to wreck havoc on the entire project, which than needs to be entirely saved back to the original older version; it happened to be necessary to use progressively older LV versions, because sw was very very old.
I would like to have LV version AND the VI's origin LV version permanently displayed - say, on the top right corner of the window, both BD and FP - and IF they differ, an warning blinking triangle.
The idea is to implement an option to choose for which RunTime-Version you want to compile your executable.
With this you could always use the newest LabVIEW development version but do not need to update all systems with a RunTime-Version.
When changing from LabVIEW 2019 to LabVIEW 2020, you need to update every RunTime-System also to version 2020.
This is difficult, if you have many worldwide runtime systems with different projects, where you can not easily update a RunTime-Version because of technical restrictions in production or access to the system.
This results in parallel use of different LabVIEW development versions for all of your projects.
Means a mess because once open a project in the wrong/newer LV-Version you have to store all changes "for older LV-Version" to continue work in right version.
Or, to avoid this, not upgrading to a newer LabVIEW development version and still working for example with LV16 in all projects.
Best way would be if you can update all projects to LV20 development system, but still be able to directly built executables for older runtimes.
When concatenating arrays, a wired empty 1D array, concatenated to an Empty 2D array will result in array index (1,0) and when this is concatenated to a populated 2D array, a top row is added with empty elements. This is in many cases unwanted behavior.
The suggest that LabVIEW includes a menu to configure the concatenate array node to ignore acting on any empty array(s) wired to that node.
Because in some cases the resulting array will end up with an added top row with empty elements.