LabVIEW remembers the folder from which it retrieved a VI or project or whatever in a buffer.
If a VI has been running (using file-IO) the folder buffer is set to the folder from which the last file was retrieved or written to.
If you want to open a new VI or whatever, the browser opens in the most recently opened folder.
It would be nice to remember the VI-folder and data folder separately. This means two buffers in stead of one.
I think it would be an amazing feature if you could have the index of the input of the build array shown. LabVIEW already displays the world "Element", why not go ahead and append the index number to the end so when you have a 30 element build array you don't have to start from the top and count down to see which index you are about to wire to. Would be helpful on the index array as well!
Get contents of all XML Node Types:
As a beginner at XML parsing, it would be great if LabVIEW had a VI (like Get Node Text Content) but for every node type (it would get the contents, whatever they may be).
All node types stated here:
are possible and may require a different set of property/invoke nodes (some have children, some don't, some have values, some don't... and so on).
Inputs: Node handle
Outputs: Raw node contents (whatever XML is contained within the tags of the Node handle), Value (where applicable), Name (where applicable)
Write general string to XML node type:
It would also be great if there was a VI (or set of VI's) that could take an input (as a string) convert it to the w3 conformant XML. It's important to use the w3 definition, rather than LabVIEW XML for external compatibility.
Inputs: Node handle, Node Type
Outputs: XML string of Node Type
This way it's a pain to "copy past" image from one to the other control. It should be possible to customize two controls at a time
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.
I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).
I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.
What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP. As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.
Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example). I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).
The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.
Although these controls are DISABLED (Not present in the source code)........
Here they are.....
This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.
Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.
Using the 3D Surface Plot in LV2011 it is possible to switch on or off either "Surface", Mesh" or "Normal".
Being in the need of the surface normal angle for some calculation I was told that this data is not accessible through property nodes.
I would really prefer accessing this data instead of calculating it twice!!!
And by the way: Displaying large data arrays in 3D Plots takes computing power running on one core only. Wouldn't it be possible to have a parallelizing option here...
The new icon editor is much better than the old one, however it would be a nice improvement if the user could restrict the number of fonts that are shown in the dropdown list for the text selection.
Realisticly most developers use what, maybe 2 different fonts when designing icons? Why not allow the developer to choose the fonts they want in the list instead of listing every font installed on the system.
Seriously, has anybody ever used "Script" for their icons?
It will be really cool, and handy, if the string constant automagically switches to appropriate predefined String Constants from the functions palette.
Example: Space Constant, Carriage Return Constant, Line Feed Constant, End of Line Constant, Tab Constant. http://screencast.com/t/GdydME7v
On the other hand, it will be very convenient if clicking inside those string constants switches to regular string constant and allows you to enter the text in it.
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.
I have searched but couldn't find any idea about that. At block diagram, if we ctrl+drag any variable Labview creates a new copy of the same object but when we ctrl+drag any terminal it creates a new object (terminal). I rarely create a copy of the terminal from block diagram. Sometimes if the code is really huge and you put a terminal inside the code without being noticed when you drag that code it becomes hard to clear new terminals. I think it would be better if Labview creates the local variables of the dragged terminals. Front panel action and ctrl+C - ctrl+V should stay same.
One of the frustrating (and mystifying) things about Labview is that it doesn't seem to know what libraries it needs to compile an installer. I have to try and guess what libraries I am accessing and if I don't realise that one of the sub vis I used has used a function from the Math Kernel Library then I have to recompile the whole thing and do another test install. Depending on the size of the project and the machines that you are using, this can take a considerable chunk of time (on my machine that can be half an hour or more). It also selects a set of "standard" libraries to install, many of which I'm not using but I must take a guess as to which I don't need. Again, I won't know if a sub vi is accessing one of them until I actually try installing it.
Wouldn't it be great if Labview could look at it's own vi hierarchy and automatically include the libraries it accesses when you do a build - or at least tell you what you need like most other languages do. (Is there any others that don't?)
The current plot legend shows the Text (plot name) on the left and the plot color preview to the right. A good feature would be the ability to switch these too. So the be able to move the plot color preview to the left and the plot name to the right.
It would be nice when Folder Auto-populating will populate VIs to LV Class (.lvclass) and to LV library (.lvlib).
When we use Folder Auto-populating in projects then project hierarchy match disk hierarchy. It would be great when class and lvlibrary hierarchy match too.
Names says it all really.
Once I am happy-ish with the performance of a VI I usually tidy up wiring etc.
Now that I have started to use Class Property Nodes very often you wish to re-order them just to make the wiring more efficient (you know, the shorter the wire the quicker the code executes).
It would be really great if we could use the switcheroo tool to swap positions of two elements in a property node. I would be satisfied if it did nothing with the wiring, because I would likely tidy it up immediately after anyway.
Not sure this idea will get much traction due to rather limited appear to most, but vote it up anyway!