When dragging a control / indicator label or caption, if you move within a certain distance from the owning terminal the label will snap to one of a set of given positions (top-left, top-middle etc). Outside this distance (or if the user presses the spacebar to toggle this behaviour), the label can be freely positioned.
The selector terminal for a polymorphic VI should display the same behaviour with regard to the owning VI icon. A polymorphic selector is currently always free-floating.
PS : Many thanks to Intaris and TiTou for their help to formulate this idea.
Say I've dropped two 2D array controls on my block diagram, and would like to change both of their appearances in the same way. I can select each one at a time, right click and head to Visible Items > Index Display. However, it would be nice to be able to select multiple items of the same type and have the option of applying the same change to all of them.
Currently, selecting both and right clicking lets me change the following:
It would be nice if LV could recognise that I've selected two identical controls and offer me the option of changing the display settings for each of them:
Expanding this, you could use the same approach for BD constants, such as setting multiple string constants to '\' code display, or disabling size to text.
I was searching for occurences of a reference to a Graph in one VI, and as I was interrupted, came back to the search result after the interruption, only to discover that the Search Result Window did actually not show ANY kind of useful information regarding the object I was searching references for:
I know I have outrageous expectations as a LabVIEW user, but this seems to me an odd lack of feature:
- From this window, I have absolutely no clue what I am searching for. In particular, if I have in the mean time jumped from windows to windows...
- ...there is no way to go back to the object these references are linked to (unless I go to one of the references and then look for the Control or Indicator they are associated with).
Of course asking for a VI information when this is provided in the list below is maybe unnecessary.
But consider this global variable whose references I was looking for:
Same thing here:
- I do not know the type of the global.
- I do not know which VI it is part of (Globals are saved in a VI).
- I do not know where I started my seach from (but that's more of a back-to-source button issue).
Suggestion: provide as much information as possible about the starting point of the search, when said starting point is an object (by contrast to a text search).
Tested in LV 2013 SP1 64 bits.
When entering debug mode (turn execution highlight on) it can be hard to see what is happening.
With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...
SubVI's get a green arrow when they are executing. So, could structures get them as well?
I find myself constantly switching between Quick Drop and palette surfing for the functions I need. Sometimes I close the palettes just because they are in the way of where I want to drop a function. But I immediately need to reopen them to find my next function.
Can there be a setting in the palette options to hide or minimize the palete once I've selected a function from the control/function palette and once I've placed the item on my front panel/block diagram it will reopen to the same palette and spot?
After we have gotten several different new tunnel modes, it takes quite a lot of context menu exercise to change tunnel mode on structures:
I propose a shortcut where we can click directly on the tunnel to toggle between valid modes:
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?
Simple idea. The Bookmark Manager would be much more useful if there was a timestamp of when each bookmark was created.
Admittiedly, the user could just include this in the note but....well....that seems slightly long winded.
I find the Bookmark Maanger very useful already but I reckon this would certainly improve it.
Apologies if this has been logged already.
It is common, in writing reusable code, to handle arbitrary clusters in variants. To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items. After access, one needs to convert the array of variants back into the original cluster.
There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository. They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow. Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.
The other direction, Cluster to Array of Variants, works like this:
But trying to reverse the process breaks:
So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also. The matching of array to cluster elements can be by cluster order rather than element name.
This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.
This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.
To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.
Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.
My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.
Typical phone exchange yesterday:
me: "just click my installer and install the program"
him: "OK, done."
me: "now run it."
him: "OK, ...... error about 2013 run-time engine".
me: "OK, install the run-time engine using the link I sent you in the same e-mail".
him: "clicking the link to go to the run time engine page....
(..30 second discussion to decide between downloader and direct download...)"
him: "click..(wait for it!)... .it wants me to register..."
me: "OK, let's forget about that. come down to the lab and I will do it for you."
End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.
While gazillions () of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.
I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to " I don't want to register at this time, just download the run-time!".
Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers.
This is an elaboration on a prior request by RavensFan:
When AppBuilder reports a file related error, such as error 8, could someone please provide a path?
I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.
I can't probe a path wire in the AB method because the diagrams are understandably locked.
This is so frustrating. No one likes to debug by guessing and it wastes a tremendous amount of time.
Thank you with my deepest respect to the AB team.
Hello LabVIEW Users,
While working with a complex configuration application, I found myself heavily utilizing in place operations. Throughout the process of contstructing the code, I found myself commonly having to create an In Place Indexing structure (pictured below). I thought it would be really nice if you could mark an auto-indexed array for in place operation. As always, I am open to suggestions, but thought this might be a nice creature feature:
Cheers, and happy coding.
Didn't find this idea posted, I think it's a must.
It would be very usefull for MulticolumnListbox Item Names in which we need to change cell values...
As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.
The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.
The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.
The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.
and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :
I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea:
"Here is a work around if you want to play around in the Windows registry:
It would be really cool to have a custom probe that could be placed on any cluster/class wire to view the data in the cluster, but instead of being displayed as a standard view of the cluster, the labels of the items would be listed along with the data type and the current value (works for scalar or small arrays, not so well for large arrays/waveforms). The standard view of a cluster probe is shown below.
I built a custom probe to do this but found that the data type of custom probes is strictly typed and therefore I have to convert my data to variant on the vi block diagram before adding the probe, which isn't great. I've attached the code for my custom probe, and a screenshot of it below.
If variant custom probes could be used on any data type, this would work.
Today, when you change a numeric control not to use the default limits, it allows you to enter your new limits, but it doesn't actually respect them unless you change the response control on the right side, which can be easy to forget.
I propose that the default value of the controls should be "Coerce", not "Ignore":
This makes sense, because if the user unchecked the check box, they probably want the limits to coerce and in case they don't, the limits already default to the maximum range of the data type, so they can't be coerced unless the user changes the limit value anyway.
I would also suggest considering that if the Response control is set to Ignore, the value should be disabled and greyed, to inform the user that changing it won't actually do anything. I would suggest getting rid of the Response control entirely, but it can be relevant if you only want to change some of the limits.
I would also consider changing the coercion of the Increment to Nearest by default, since it's probably the most common option, but that could be debated.