Here we consider a global cluster (first use case) or a function that outputs a cluster and is viewed as icon (second use case).
NOW : GLOBAL VARIABLES POINTING AT TOP LEVEL GLOBAL CONTROLS ONLY
In order to access one item within this global cluster, I have to put on my diagram a global variable pointing to the cluster, and use the "unbundle" function to extract the desired element. Right clicking on the global variable only allows to browse top level controls contained in the global VI (can not directly point at cluster components).
BETTER : GLOBAL VARIABLES THAT CAN IMPLICITELY UNBUNDLE ANY GIVEN GLOBAL CLUSTER COMPONENT
First you would put on your diagram the global variable, pointing to the cluster. Then right click on it and choose in a tree-form menu (alike the menu to choose among properties/methods of an object) that allows to select not only top level controls, but also controls contained within clusters. The global variable would then point directly at the cluster compponent with a name like "Cluster.Component".
Using unbundle function is cumbersome and can be nicely avoided in this situation.
OTHER USE CASE : ICON VIEW VI THAT CAN IMPLICITELY UNBUNDLE ANY GIVEN OUTPUT CLUSTER COMPONENT
For VIs that output clusters (e.g. when the number of outputs is big), the same trick could make it easier to reach specific output cluster contents without the need for an unbundle_by_name operation, at least when the function is viewed as icon.
Sorry, not time for artist views ;-)
I like to compare two build specifications of two different projects.
To do this it would be very helpful, that the build specification dialog box is not modal and that i can open each build spezification of each project at the same time. Resizeable would be also nice.
When defining a test case in a unit test you often need to import the connector pane or import control values.
This can take several seconds but there is no sort of indication of when the operation is running or complete. It would be good to at least have a busy icon for the duration if not some sort of progress bar.
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.
how about a "Delete all But this" (similar to Notepad ++) for cases in an case structure. This would save the case-structure and the code inside for the selected case.
I know, that I could delete the structure, keep the active case and get a new case structure around that piece of code...but that's not comfortable.
Naturally, the first thing you want to do when a unit fails is go to the test definition to understand why it has failed.
I propose that you should be able to double-click the test name or even better the failed test case to launch the .lvtest definition directly from the results window.
We need the additional properties of the used LabView Editor:
bitness: 32 or 64 bit
ServicePack Number: 1,2,3 ....
Patch Version: f1,f2,f3 .......
So, what i like to have is, that i can get the above listed properties from the currently running LabView Editor, programmatically!
See also forum discussion for the problem:
As in the subject.
Now when you create an array the indexes of the array can be only labeled as the static comment field. There is not any build-in label/handler which could be used. Current situation looks like that:
It would be better for readibility if developers could name the indexes and use it later on.
Picture represents the idea only, whole point is the description shoud be a build in handlers.
Now LV names first four indexes (when you hover over on it) as column, row, page, vol; later on are only dim 5, dim 6 and so on.
I believe if would increase readibility and save coding and debugging time.
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.
The Unit Test Framwork provides some useful statistics on code coverage and project coverage of tests but these mean that it is much slower than other frameworks.
In particular the project coverage causes a very long results load time (>5mins AFTER test completion) on a RT target as it appears to load (and possibly compile) the VIs for the target.
It would be great to have an option to disable these high levels of reporting for day to day tests to speed up development.
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?
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?
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.
If you've ever tried to use the LV Web Service > Session VIs for sessios, authentication, user management, etc., then you'll quickly notice that they're lacking an important feature: the ability to detect when a user session times out (expires).
I can think of two important use cases as of why you'd care:
(1) The user/client is viewing sensitive information (served to him by a LV web service), and then decided to walk away from his computer as we do sometimes. Any Joe walking by might then get a glimpse of something he shouldn't.
(2) For logging purposes. It might just be nice to know when the user logged in and when the user logged out for your IT records.
With a securely built web service, you could detect the user isn't there anymore, and direct the web client (Chrome, FF, IE, etc.) to redirect the page and destroy the session.
There's a sister idea that goes along with this, but I don't think I'll post in a separate thread unless needed. So, another way to detect session timeout events would be to get the session ID cookie (from Create Session VI), store each cookie in memory somewhere, and essentially poll them in a background loop for session information (ie session still exists?).
Ho hum, maybe I'm the only one building web applications of this type, but it sure would be a helpful feature in my opinion.
Currently, if for some reason you wish to move e.g. the x-axis of a graph to run along the top of the graph display, you have to do this at edit-time by right-clicking the (x-)axis and selecting "Swap Sides". I have not found any property or invoke node to do this at run-time.
Instead, I have to duplicate a scale (at edit time), move one using "Swap sides", then in the program I need to programamtically track and control which one is visible at any given time. Since the graph area properly resizes/moves as the scale(s) move in and out of visibility, I see no reason for why the "swap sides" functionality can't be a boolean property accessible at run-time? (But then again, there are a lot of things I don't see, especially on the back-end of the LabVIEW environment...)
As a side note, it seems like you can't even swap sides at edit times for a chart.
This idea is related to this idea: