Simple one, allow me to create new folders from within the right click menu in the project explorer window.
Currently I have to use 'explore' then create the folder through windows in the target directory.
As far as I can locate, this hasn't been posted on Idea Exchange yet.
What I'd like to be able to do is change the default colors and visibility of various components of block diagram items. For example, I might want to color the background and sub label of my timed looped structures so that they improve the appearance of my code, like NI has done in the Bioreactor example code with a free label and custom colors.
Rather than setting these colors/font sizes/label visibilities for each structure I place, I'd like to be able to set them only once. Currently, the sub labels' default visibility CAN be set in tools»options, but not the coloring.
I want to be able to add a dynamic tag like <my exe version> to the Welcome title and Welcome message the installer displays to the user when they run the installation. That way, they can see what version of the exe they are installing.
In the Description and Tip Dialog the Tip can only contain one line. On the properties page Documentation the Tip strip can me multiple lines long.
This is not consistent. Could you please allow to enter multiple lines in the Description and Tip Dialog?
When you are already at it you could also unify the labeling. In the "Descripton and Tip" Dialog, leave away the text "String" and use Tip strip instad of only Tip.
(The Description and Tip Dialog is opened by selecting Description and Tip... in the context menu of a control or indicator.)
Ever since I remember, when you use the "Write to Spreadsheet File.vi" and cancel when offered a dialog box, it throws up an error 43.
The vi does not have an error out connector so there is no way to stop this behaviour. I know that it can be overcome by using an explicit file dialog box so that the path isn't empty but then why offer the functionality of having it offer a file dialog box in the first place? It's an easy fix as I have to do it myself every time by saving a custom version and changing the internal error handler to no dialog. Just change that as the default and problem solved.
In a Mixed Signal Graph there isn't a documented way to programmatically change the 'Group' names.
They can be easily changed inside the editor, but not at run-time.
This request has been already discussed several years ago (see here)
It would be useful to be able to name (either automatically or manually) the sliders of a Slide control (or needles of a Meter or Gauge). The use-case I have is for saving a configuration file (currently requiring typecast to/from a cluster with names), but it may also be useful to be able to Unbundle By Name. I found this post in the LabVIEW forums showing this idea has been talked about in the past also. Here's an image from that post:
A related idea would be the ability to replace the control with a Cluster control, and vice-versa. Currently, this requires creating a typedef and manually recreating the cluster.
Since Windows Seven, the system exec vi is not displaying accents but other ascii caracters. Depending on the Windows language I suppose.
This issue has been discussed since 2010 in different threads, manly this one : http://forums.ni.com/t5/Discussions-au-sujet-des-a
and nothing has changed.
Please add this to you next SP
Typically, when working with classes, one tend to work on one class at a time. Consequently, opening a specific dynamically dispatched VI (from another VI) should result by having the class implementation opened (like if it was opened from the lvclass). The Choose Implementation dialog should not be shown (in most cases).
I did some quick statistic, and in most situation, I care about the class implementation (about 80% of the time). In some instance I care about parent or children implementation (about 10-15% of the time). Finally, in some rare instance (<5% of the time) I care about the sibling implementation. Note: I confirm this with a few of my colleagues as well.
So what I am proposing is that by default we should not see the Choose Implementation dialog. When we specifically want to see this dialog we could use either of these methods:
Comment and improvements welcome.
NOTE: This is blatently stolen from a thread I started on LAVA here.
I would like to be able to specify a VI or VIs in my project that would run when some keyboard shortcut (ctrl-shift-R was suggested) was pressed.
Since in most cases a project is used to create a single application, it makes sense that when you open the project, you would want ot run the top level (main) VI in that project most of the time.
If I right-click with the wiring tool on an output terminal and select a new item from the palette, LabView should assume that I would like to wire that new item to the place where I right-clicked. If the item I selected has only one type-compatible input to the output I originally right-clicked, it should automatically make that wire connection when the new item is dropped. Similarly, if I right-click on an input and select an item from the pallet, if there is only one compatable output on the item I selected, LabView should go ahead and wire that up when I drop the item.
It's important that when we've got a newly created SubVI, we document our code accordingly and draw an appropriate icon for it. This helps other users understand what types of functionality we've encapsulated within a particular VI.
This isn't always the case, though.
I think I understand that some people are pressed for time, or unaware of how to actually edit the icon of their VI, and that these shouldn't be reasons as to why their code should be harder to read by other users trying to support them because of that.
What's the big idea?
I believe what would be useful is for SubVI icons not to use the default smiling oscilloscope face, but to instead give an indication of two things:
So, how would it work?
I think the way that it would work is that either it'd perform a summation of the most common palette used in the Block Diagram, or use icons based on a rating for how important they are to display; for example, there's plenty of errors that could get thrown when using DAQmx VIs, so if the SubVI contained some DAQmx VIs and a lot of basic maths, it'd be more useful to show that it relates to DAQmx than it does basic computation.
... Just an idea.
If a class is contained in the private data cluster of another class, this is the LVOOP equivalent to an Association (as OOP concept). I'd like to optionally display this relationship of classes in the Class Hierarchy window. It should also work for nested structures (class in array, cluster, DVR).
As used from normal BD programming, different kinds of wire should be used to identify details of the relationship:
The following would be nice to have, but partially difficult to implement:
In addition there should be a way to annotated the associations to indicate when the intended use is restricted to a child class, such as class that contains objects of the type of the same class. Here the association would point to an ancestor of this class. Either we should be able to put a comment on the 'wire' to document this intention. Ideally we could be able to wire classes with recursive associations (which are not possible in LVOOP, hence this should also not have any effect on the code by only be documentation), and link it to the implemented association wire.
one of my main errors while programming were infinite loops due to instruments that responded not as expected or numerical criteria that could not be fulfilled.
I got rid of these problems (with instrument I/O in particular) by introducing timeouts into my while loops, i.e. just counting the milliseconds and exit upon timeout.
Hence my idea is to integrate an optional timeout into while loops to simplify this procedure.
Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.
Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.
I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:
Almost every time when I'm building an application, I always have to reconfigure the created ini-file (based on labview.ini file) denpending on what to use.
Then I have to go search for the tags in labview.ini and copy them in my ini file.
It would be easier if you could hit a configure button in the application builder so you could select which setting you want to use in your own ini file and which one you don't.
I'm especially struggling with some standard ones like useLocalDecimalpoint
Kind of related to my frustration I mentioned in this idea, I would like to have a one time auto grow option for structures. If the structure is not set to auto grow, allow the user to select to Auto Grow once.
You can accomplish this now by turning on Auto Grow, then go back and turn it back off.
If my other idea was accepted, then this would also be a nice add-on that would override the global setting and do the one-time auto grow.
I would like a better way to clear the list of recent files and recent projects in LabView. It is often disireable to clear the history when changing to a different project or a different user. Currently the user must close LV, edit the .ini file and restart LV. I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.