We can right click and insert a VI using a right click. However it would be nice if we could hover over a wire and use Ctrl-V to paste a VI and have it get wired automatically. Granted it may not be able to wire everything but it could be fairly intelligent and wire up what it can.
If you have a project under source control but haven't yet checked it out (because you wouldn't think LabVIEW would modify some attribute without telling you what it is...), when you try to save the project allyou get is a dialog box stating you can't save it because the file is read-only.
"Project save" should trigger the same process with any VI, i.e., prompt you if you want to check the file out ot source control.
In Front Panel we see that the Cluster is bound geometrically. It makes it easier for the user to create a cluster this way. But There could be other ways in which a cluster could be created. Say we have a new feature which allows user to group controls into a cluster like lvlib groups vi's, If a way to add controls to a cluster by name is introduced it would give each control freedom to be anywhere inside the front panel and not necessarily bound geometrically inside the present cluster bounds.
Please inform if any such feature already exists.
As of LV2010SP1, there is no good way to interact with the Right-Click menu of a control programmatically. You can create a custom right-click menu for a control at edit time, and as long as you save the menu with the control (saving it as a discrete *.rtm file doesn't work--see CAR #256160), you're in business.
But if you want to make sure multiple controls all have the same menu, you're pretty much out of luck. There is no way to programmatically load an *.rtm file for a control. The best you can do is build up the menu one item at a time using the menu primitive functions. And you have to do that on menu activation event, because you can't get at the control's menu reference any other way.
This is pretty kludgy.
The other solution is to make those controls strict type definitions, but that isn't ideal in a lot of cases. For instance, I want to make sure all the XY Graphs in my application have the same RTM API, so I could use a single strict typedef, but that sucks if I don't want them all the same size, etc....
So here's the idea: fix runtime menus for controls.
Currently the 'array build' gives you only the option to merge by rows. If you want to merge by column you first need to transpose the two (or more) input arrays then merge them and then transpose the array again. See VI example attachted. I think this should be changed because it gives a overhead on transpose VI's on your diagram. Therefore I suggest that the 'array build' block gets a option where you can select to merge on columns or rows when a 2D array is used as input.
Its good that NI has introduced mouse scroll wheel event with LabVIEW 2013.
I feel it needs to be slightly changed.
Consider the following scenario:
1. A VI with numeric control on Front Panel is running.
2. Enter the value for numeric Control as 9.
3. Use the mouse scroll wheel to increase the numeric value, it goes as 9, 10, 20, 30...... etc.
4. Again Enter the value for numeric Control as 9.
5. Use the Up arrow button from Key Board to increase the numeric value, it goes as 9, 10, 11, 12, 13, 14... etc.
I feel useful if the mouse scroll function also behaves similar to Up arrow button from Key Board.
(In older version of LabVIEW, Up/Down arrow button of Key Board were behaving how the Mouse scroll works in LabVIEW 2013)
There are many array functions that don't need to depend on the dimensionality of the array - for example most of those in the "Probability & Statistics" menu (Mean, Median, Std Deviation etc) and some in the Signal Operation (like Scale, Normalize). But if I want to use one on a 3D array, I must first make a copy by reshaping to a 1D array, which can be very memory-expensive. I'd like a node on the "In Place Element Structure" which accepts an array of any dimension, and makes the data available as a 1D array of that type.
I've suggested a similar idea before here, but perhaps I made it too complicated to receive any comments! I keep running into this problem, so lets try again.
All the provided glyphs in the ...\LabVIEW Data\Glyphs\ folders are 32x32 PNG files. Even if the actual glyph itself is smaller. The Icon Editor in LabVIEW 2012 centres on the glyph 32x32 image and therefore whether the actual glyph graphic is smaller than 32x32 you can only put it in the top left quarter of the icon.
Try it with LabVIEW Data\Glyphs\Actions\unsupport.png and try to put the glyph in the bottom right hand corner. You can't!
They all need resizing to the actual size of the glyph.
I have created and used glyphs 15x15, 20x20 and other sizes and the Icon Editor loads them without issues, and the cursor is central to the glyph.
Description of the problem :
If we build a project using Classes (or Xcontrol), we must be careful when we names the subVI of a class (or Xcrontol), and take care of NOT using character such as "é", "ç" or special character in the names of the VI. If a sub-VI of a class, or of a Xcontrol, a class itself, or a Xcontrol itself, have a names using one of this character, we can build the project, but the .exe will not run on some computer (such as Chinese, Russian etc) .
The problem is only for names relative to class or Xcontrol. I never had trouble with other VI. And is a shame because when we create a Xcontrol, a class, A class property, etc... Labview automatically suggest nice name like "façade blabla", "écriture blabla".
So I suggest :
- Solution 1 (it will be the best) to allow localized names in class and Xconrtol, and when a project is build, the .exe will run everywhere on the planet.
- Solution 2, don't allow these names or at least warn us when create these VI, and also DON'T automatically suggest names that will cause trouble !!!!!!!
After selecting an entry from the quick drop list I have to re-open it again for each item I want to place. Why not adding the possibility to keep it open showing the last selection? E.g. if I select the TCP Open item most likely I will use a TCP read or write in the next step. I think this could be easily done by copying the behaviour of the Control-/Function palettes which have a Pin to make them sticky.
This could be in addition to the existing Express VI called Elapsed Time. This function or VI is simplified: without all the String outputs, and not an Express VI.
To quickly make a reference of a specific type, it would be nice to have a right click option to "Change to Reference" when an item is selected. It does not have to be a reference to a particular control or indicator, it could just be a vi server reference of the same type.
I often add comments to BD to describe specific behaviour depending on different states which would be best within a table. At the moment there are a view ways to do so:
1. Using normal comments and spaces to add a table-like design - not so good
2. The same as 1. but using a font like Courier or Terminal together with "|", "+" and "-" - better
3. Using a 2D-String array - don't like this
4. Do it in Excel and add a screenprint in BD - don't like too
I think the best way would be the possibility to have a 2D-Comment where you can add columns and rows together with header.
When I work with well structured and big projects, I usually have to expand numerous folders/items to get to the point I am interested in. Usually it is close to the item I was interested in last time I opened the project.
I propose to have an option for the Project Explorer to remember the expanded/collapsed statuses of the items and also the selected items.
before closing: ->> after opening:
before closing: ->> after opening:
From the developers perspective... events are interrupts and timing sources are interrupts. Do we need two separate way to pragmatically creating these (event registration refnum and timing source string) and reacting to these (structures)?
I realize there are features one has and the other one doesn't... but there is so much overlap and so much potential if combined.
This is really just a small time-and-space-saver...
It would be nice if the * Array Elements functions found in the Numeric and Boolean palettes would work directly on clusters:
Yes, the names would probably need to be changed ... but on the positive side, these functions do not even reside in the Array palette!! (Maybe they were destined for better polymorphism from the start )
It would be an added bonus if Darin's complementary idea was implemented at the same time.
if a control definition is missing we can replace the new control by coping the new control to clip board and pasting on top of the control. This preserves the wiring of the control on the connecter pane.
Similarly we can have the option to replace the missing VIs (?) by coping the new VIs in the clipboard and pasting it or
add an option on in the replace menu like replace from clipboard, and it will preserves the connections.