The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.
We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)
I would like to request a feature that allows us to easily and permanently remove any entry in the list.
(...maybe it could even show for pinned entries?)
IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.
It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.
These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.
After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go.
We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time.
So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk.
Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.)
In summary, there should be a menu entry that ignores indicators when making values the default.
It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.
With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.
For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.
For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.
[admin edit: Adding animation image at the request of the OP]
Make it easier to find the right product in the uninstaller
If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult.
The fact that things a split into so many separate components is practical, but the components should be organized better:
They could be:
Allow us to specify a new source location
If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original.
Recently, user cprince inquired why all of the possible Mouse Button presses were not available in LabVIEW. In the original post, it was not clear whether this referred to "normal" mouse functions (as captured, say, by the Event structure) or whether this referred to the Mouse functions on the Input Device Control Palette. The latter has a Query Device, which shows (for my mouse on my PC) that the Mouse has 8 buttons, but the Acquire Input Data polymorphic function for Mouse input returns a "cluster button info" with only four buttons.
The "magic" seems to happen inside lvinput.dll. If, as seems to be the case, the DLL can "see" and recognize 8 Mouse Buttons, it would be nice if all 8 could be returned to the user as a Cluster of 8 (instead of 4) Booleans.
I would love an update to the signal processing VI's contained in NI_MAPro.lvlib to support waveforms with a SGL Y-value representation. The library is locked and most VI's call dll's that are not able to be modified anyways (by me that is, I am not all that strong in traditional text based languages). It would be nice to also support SGL waveforms within the .llb's contained in vi.lib/measure; although these are mostly unlocked and able to be modified.
Working with a cRIO, the FPGA to host DMA channels encourage the use of SGL data type so I went with it and kept it as SGL throughout my application. For some functions I turn my SGL array into a waveform with SGL Y-value representation. I was disappointed to learn that most of the signal processing waveform tools contained in NI_MAPro.lvlib do not support the SGL Y-values.
The predessesor application was done on the usb cDAQ line that i was using DBL representation Y-values. I want to re-use a lot of code and was hoping the waveform signal processing VI's would accept SGL Y-values. For now I am stuck converting my data type for the sole purpose of re-using code; at 50kHz on 36 channels this can become a performance issue.
The title says it!
It is often confusing "Which is the opposite end in a queue?/What does opposite end mean?", esp for new user of LabVIEW.
Seems here, even the author of the LV Queue primitives was not able to recollect its name correctly.
Also, please see below from the LV Help.
Currently, the only object that we have access to in an Event Structure it the control itself:
This is not what I am interested in, most of the case, when I am working on the BD.
Rather, I'd like to either find the terminal, or local variables, references, etc.
Moreover, going to the control using the above shortcut may result in a messed up FP, not mentioning cases like this:
where the control may be hidden or invisible because it is in another tab than the one currently selected.
Now, I know that some will argue that the control terminal is most of the time in the event structure (see for instance this thread)...
But read the thread's comments for counter arguments: we would be talking about the Value Change event, but this is not what I am talking aboutin general: any event for that control should give access to the control's terminal (and BTW, it could very well be an indicator) and, as for a terminal, to this list of related objects:
(The last one courtesy of this shortcut plugin)
The Open/Create/Replace file I/O primitive is pretty powerful. It will check to see if the file is there for you, and, if not, create a new one. I use the "Open or Create" option often when generating multiple delimited text files in long term tests. When a new file is created, I need know so I can add a header, and I need to skip the header operation if the file is being appended. Sure, I could check to see if the file exists before trying to open it, but then wouldn't that just make the power of the Open/Replace/Create function redundant? Some operation took place based on my input to the "operation" terminal, and whether or not the file exists. Unfortunately, I have no idea what that operation was, because the function doesn't tell me. Let me know if the Open/Create/Replace function created a new file so I can add my header.
This is not without precedent. For example, the "Obtain Queue" primitive has an option to create a new queue if a queue of the given name is not found. It let's you know if the new queue was created:
A value change for the autoscale setting of a graph / chart scale is currently not registered. It can only be detected by polling for the scalefit value. The range of detectable events on charts and graphs is currently incomplete. The scale range change event and the autoscale range change event trigger at the same time in unpredictable order. This makes it hard to detect whether a user manually adjusted scale minimum and maximum or adjusted the autoscale settings value in the scale attribute. Different user actions all trigger a scale range change event without any way to discriminate the cause of this event.
There are a lot of ideas about improving the navigation of the Find Project Items window, but I could not find this one. When I search for a project item and get a list of matching results, it would save a lot of time if I could select the ones I want, GoTo all of them at one, then open them all simultaneously from the project window. Opening multiple items has been around for a very long time.
1. Select first result
2. Go to item in project window
3. Open item
4. Edit item
5. Save item
6. Close item
7. Go find results window
8. Select second item
9 Repeat 2 thru 7 again and again
This would take about 70 steps for 10 items
1. Select all results
2. Go to all results in project window
3. Open all items at once
4. Edit item
5. Save item
6. Close Item
7 . Repeat 4 thru 6 for all items
Under 35 steps for 10 items.
I've been wondering for years now why the LV Save (& Save All) dialog is quite unusual in terms of its layout & usability.
Redesign the "Save Changes?" dialogin accordance with the standard dialog design criteria as follows.
As requested by this fellow 8 years ago: http://forums.ni.com/t5/LabVIEW/Multiple-pattern-l
Currently, we get a single line:
This results in this kind of mess courtesy of the IMAQ Load Image Dialog.vi):
To update the snapshot illustrating this other thread, here is an example of MS Word in action, illustrating the desired behavior:
In other words, it helps cleaning up the results, while using a single dialog window for all kinds of different files (which will be dealt with differently down the line).
I am not sure how multiplatform that can be, but here is the file open dialog options from TextWrangler on MacOS:
so it seems that can be done.
The thread I am referring to had a link to a Windows API call, but the link is dead (probably the result of the recent disastrous site cleanup). And of course is not multiplatform.
When the abort button is pressed, and the development environment is present, the block diagram should be shown and the portion of code that was currently executing should be hilited.
Right now the only way possible to set the tabbing order of controls on the front panel of a (sub)VI is to use Edit >> Set Tabbing Order.
I would like a VI Server property/method to be able to programmatically set the tabbing order of the controls on the front panel the way I want. This way I can write a script to fix a large number of VIs without needing to manually click through each one. (Of course I would be responsible for programmatically figuring out the order I wanted, but I could make some general assumptions like following the top-bottom left-right on the front panel existing layout, or following how they are connected to the connector pane, etc)
When working with User Events as an API between modules there is a nasty little thing which unfortunately keeps rearing its ugly head.
If we retrieve a cluster of User Events (or an Event registration refnum) from a module with events we should be listening to and wire this to an event structure we get a memory leak if not all events are handled. This particularly occurs whenever the API is extended and not all listeners have been updated.
It would be much easier to track down these kinds of problems if the Event Structure would display which User Events are in the associated Registration Refnum but are NOT yet handled. This would be a great too in tracking down rogue Events and eliminating possible memory leaks due to implementation errors.
Currently one has to iterate through ALL of the user events and observe the warning "this event is handled in another case" in order to find out if all have been handled or not.
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
the input value of the conditional terminal should " pass through "
(like the "case selector" of the "Case Structure")