Presently LabVIEW and it's toolkits ship with a number examples. At the same time there is a massive amount of information and examples with content like the examples and the things that are much more. When I am searching for an example I often can't remember if I saw it on the web or in the examples. So first I open the Example Finder, a tool that I really like, and search for things there. Then if I don't find what I am looking for there I open up a web browser and search the NI Communities, then the NI forums and other forums (like LAVAG.org). It would be nice that instead of having to use to programs the Example Finder could give a list of possibly related items on the NI forums. I think this could be managed using the existing tagging feature of the forums with perhaps by having an #example_code tag. A crawler program could then parse though the tags and grab the links to pages of possible matches populating a database. Then this database could be access by the Example Finder for related info.
Another option would be for me to be able to find a link I like and attach it to my example finder or perhaps to my NI.com community account. That would be useful.
Actuallly, if there was an API for example finder that'd work too.
If you are using Global Variables in a project, and you drag the control from the Global VI's front panel to the block diagram of another VI, the item gets placed on the BD as a constant. It is more desirable that this action drop as a global variable node associated with the dragged control. If either the global VI in the project or the global VI's icon is dragged to a diagram then the result is a global variable node, but then always defaults to the first control in the global so you have to manually change it (this default choice is natural as LV would have no clue which control you wanted, fair enough).
This idea is to create some way of moving a control from the front panel of the global VI to the block diagram of another VI in such a way that LabVIEW knows to drop a global variable node instead of a constant. Because changing the standard behavior for dragging a control from any panel to any diagram would result in user interface inconsistencies, the suggestion is that ctrl+alt+drag be used to indicate that the user is performing a special drag, and when this drag is from the FP of the global VI to the diagram of another VI, LabVIEW should drop a global variable node.
Note: before I get people commenting that GVs are bad bad bad and should be removed, this idea does not attempt to rationalise the need for (or hatred of ) GVs, lets try and leave that for a different thread.
Sometimes when searching, certain subVI's take forever to get through, and they're almost never what I'm interested in searching. A simple checkbox in the VI properties that said something like "Skip this VI when searching" would fix this neatly.
(slight aside, two of the slow ones have a bunch of .NET calls in them)
The only other way I know of to accomplish something similar is to password protect the slow VI's, but I work on a team and that would be a hassle for everyone.
This is related to the following suggestion, which is to allow multiple search windows to be open. If that were implemented, it would at least make the slow searching less painful, by letting me keep previous results. But I often end up wiping out the search results by doing something like 'find all instances', and then I'm back to the slow search.
Technically, I suppose you could consider this a bug.
The situation is this:
Perhaps there's some technique I'm missing, but this is causing our team a pretty significant loss in productivity. (Note that we have no issue with re-using the .lvbitx from RT host code, that works just fine - it's using an existing front panel in interactive mode that you can't do without recompiling it locally.)
Change the target IP address:
Now you have to recompile...
When you have a VI with multiple subVI’s, you often have numerous windows open – maybe not during the development as you finish one subVI, close it, and then return to the main VI. But if you inherit a VI from a coworker and you’re trying to figure out what his code does, or when you’re in the support department as I, it would be a nice feature to group all your opened windows.
See my illustrations: The first one shows a mainVI where I have opened two subVI’s making it a total of 6 windows. The next one shows the same example but this time grouped into tabs. Of course one should still be able to quickly separate the tabs into windows.
One other feature could be to make an option named “Lock front panel to block diagram”, meaning that if you click a tab on the front panel, the tab on the block diagram automatically switch to the respective block diagram and vice versa. Again, this option should be easy to disable.
This idea differs from Jack's idea “LabVIEW IDE Overhaul”, because it does not merge the front panel and block diagram into one window – that part is still separated in this idea. Also, Jack’s IDE-change was presented to users in LabVIEW 8.0 Beta, which is about 7 years ago! I personally think that the LabVIEW users are ready to experience LabVIEW with tabs. I don’t think it’s a duplicate of Jack’s idea, but even if you guys think it is, my opinion is that it is time to give it one more try…?
Just as NI MAX and License Manager are applications that come bundled with Lab VIEW, could NI develop a Converter that converts a single vi or library, or project from its current version to a user-specified version? Within the application itself will be the heritage hierarchy which maps both direct and indirect conversion processes, which the user need not try to manage. Hopefully, we can shine some light on an issue which could resolve the myriad of requests for which the entire Version Conversion Forum was formed to begin with. Thanks.
Every time I have to figure out how to use a new kind of control, I wonder why there is no "help" option, as there is for any kind of thing on the block diagram. I have figured how to location this documentation by searching on the various general front panel documentation pages, but it seems that it ought to be a pretty straightforward association. Many controls have complex interfaces that require some explanation (vector of clusters of vectors of ...).
Lately I had to print the API documentation of a set of VI's I have done.The documentation will be printed as the order of the listed VIs in the print Dialog.
The problem is there is no way to sort the list of vi's.
What I propose is to add two way to sort the list:
Sort By VI Names Button
Drag and Drop Sort
Labview implements lots of functionality in the right click menu, resulting in large and deep menu hierarchies. Often I want to select multiple items, but the context menu disappears after a single selection requiring me to go back to the original item and renavigate the menu tree. That's a lot of repetitive, fairly precise mousing.
I'd like to have a hot key that prevents the context menu from disappearing after I select an item. For example, if I held down the Ctl key while deselecting "Label," I could immediately move down to "Caption" and select it, making the whole process much easier.
I'm using Key Down? and Key Up events to turn the keyboard into a series of switches for a behavioral experiment. For example, I want the user to push down Caps Lock with the left hand, Return with the right, then use the appropriate hand to do a specified task. By monitoring Key Down and Key Up events, I can capture the timing of the user's "button sequences" (to the accuracy of Window's clock).
Key Down? provides three indicators of what key is pressed -- Char, which is an I16 representation of the Ascii character (and hence can be "converted" easily into a string one could test, e.g. is this "A"?), VKey, an enum saying if the key is an Ascii character or a "special" key (such as Caps or Return), and ScanCode, which is another I16 that corresponds (somehow) to each key on the keyboard. There are also boolean indicators that can tell you if Ctrl, Shift, or Alt are being simultaneously pressed. Of these, the least "transparent" is ScanCode, as there is no obvious way (other than placing a comment on your code) to know that 58 corresponds to CapsLock.
Unfortunately, Key Up only provides ScanCode! So while I can write "nice" code that can more-or-less self-document that I'm testing for Caps Lock or Return (simply wire VKey to a Case statement, which will allow me to have a case labelled "Caps", pretty obvious, no?), I don't have such functionality with the Key Up event.
Suggestion -- add Char and VKey inputs to the Key Up event! This will make it "symmetrical" with respect to Key Down?, and will enable producing Key Up code that doesn't need to rely on "magic numbers" (Scan Codes) for specific keys.
Currently when a vi is called asynchronously, it will live - even when the calling VI stops. This may cause problems in some cases - for example, code that uses the "first call" function. During development, it is not unusual to have a VI stop inadvertantly without proper cleanup. With Asynchronous VIs running in the background, you must shutdown and restart your project to clear out these Asynch VIs. It would be nice to have an option on the OpenVI function that caused the Asynch VIs to abort in the event that the calling VI shuts down inadvertantly.
My application uses a series of files to configure it self and I need to search in arrays to find which are similar to a given reference.
My solution is to use a for with a Match pattern VI and some logic to do the operation.
I believe that "Search 1D Array" would be faster than this implementation if it had the option to use wild cards ("*" and "?") as "element" input.
Other option would be include a flag "Exact match", by default set to TRUE to behave as is today or FALSE to stop on first occurrence of "element" in the array that contains it somewhere.
For example, if element = "ode" and array element = "model", it should set as a match if Exact match is set to FALSE.
I can run exe's built using an application build, but not the "setup.exe" from an installer build (the "Run From Build" button is disabled and grayed out):
As far as I understand undo management in XControl, "DisplayState" is memorized each time "State Changed" is set to true in "Action" Cluster. Undo step is limited by the configuration of "Maximum undo steps per VI" in LabVIEW environment.
It would be interesting to have more control on this mechanism:
- be able to clear the undo memory
- be able to skip a memorization when "State Changed" is set to true. (idea : memorized the state only if "Action name" is not empty.
- be able to set the maximum undo step independently from LabVIEW configuration (idea : use the init ability to define this)
Last item wold be useful to avoid too large memory consumption when "Display state" contain lot of data.
It's sometimes bothersome to have to go create an event then go get your control and drag it in to that new event case. I would like to be able to drag and drop a control into the event structure in any case and have the option to either place it in the case you have currently selected, or pop up the dialog to create a new event case, then have it dropped in that new case automagically.
Currently all ROI contours have to be the same color. There have been many instances where it would have been useful to be able to set the color of a specific contour.