Add a limitation for the minimum field width for numerics.
The maximal accepted value should be limited according to the format and the display style of the numeric. For example 2 for a U8 with hex display.
Currently, this missing limitation can lead to confusing code/display. For example, with a minimum width of 4 and "Pad with zeros on left", above numeric will have a "U16 look".
A particular thought would be needed about how to adapt the entered value when the format or the display style changes.
Not obvious. The cure could be worse than the disease !
What do you think about this idea ?
When I start LabIVEW, it will eventually ask me to log into my SCC (I use Perforce) as part of the startup process. Unfortunatly, LabVIEW requires that I type my password into the Perforce login dialog and then Perforce responds within 60 seconds or this will fail and I will get the following dialog:
So, if I start LabVIEW and then go off to do some other task and miss the window, I get this error. If I then open a project, it is not linked to my SCC system and none of the SCC status indicators show up on the project items. The only way to fix this is to close LabVIEW and reopen it.
All I am asking for here is a 'RETRY' button next to the 'OK' button so I can get a second chance at this. It is a small thing, but it would make my life much happier... So, please vote for this idea, even if you don't have the same problem.
Spurred by Darren's latest nugget, I think it would be an excellent addition to the feature to be able to retain wire values for all subVIs of a particular VI as well as the VI itself. Several times, I have found myself having to run a VI a couple times to get to the point where I can satisfactorily examine the data flow. There is a JKI RCF plugin by Vishal posted here which implemented this, but native functionality would be much preferred.
I'm not sure how best it could be implemented in UI so as not to disturb those who don't want this, and I can forsee a hairy situation arising if a particular subVI is called from a different hierachy later. Ideally, the subVI would retain values for the last execution in the retained hierachy, but obviously that's incorrect in the grand scheme of things. I'd love to hear other ideas on how to handle that scenario.
I often pass an error wire out of a for loop. It auto-indexes, as most outputs of a for loop do, but I never retain the auto-indexing.
The current default behavior is:
But I think the default behavior specifically for an error wire should be:
There are already "Simple Numerics" and "Simple Strings" on the classics menu. I'd like to see "simple clusters" and "simple arrays" added.
Or else give us the ability to customize the Cluster and Array controls to reduce the wall size of the bounding box down to a pixel width.
I want to find string constants containing a particular word, say "LabVIEW", in my LabVIEW project. At moment, I can use "Find and Replace" to search for String Constant, but this returns all the string constants I used in my LabVIEW project. There are just too many of them. It would be really nice if there is a filter option where I can search for a particular subset of the string constant, for example, a particular field where I can enter <*LabVIEW*> to serach for string constants containing teh word "LabVIEW". The same applies to searching for path constant and numeric constant.
Why does the block diagram span 1000's of pixels. I would like to allow a block diagram size maximum to be specified on a vi basis. This way I could set my vi to limit the block diagram from 0,0 to 1200,800 for example. This not only forces good style but also prevents the inadvertent placing of functions off the screen (have you ever dropped a functional global call by mistake off the field of view by mistake and tried to debug the vi?). This feature would be optional so use it if you like (or impose it on your new programmers). If set on an existing vi, the code would be moved into the field of view with a warning message if position coerrsion is needed.
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.
In installer creation, provision should be available for executing any third party installer/executable before starting the LabVIEW application installation.
After installing any application developed in LabVIEW, we can see that in Start > Program > <application>, is there any way we can get uninstall option in same menu (Start > Program > <Application uninstall>. (so it remove all the components were installer with the application)
I would like to suggest implementing the capability to add a bulk of users or computers in Volume License Manager. I suggest to allow a text (maybe csv or similar) file's content to be imported in, which would greatly speed up the setup of a new VLM server. Addionally, for the adding computers, it would be good to discover all PCs on the network and allow the administrator to select the computers to add using a checkbox.
When replacing a bundle by name function with an Unbundle by name function or vice versa, the element names should be maintained. Currently when you replace this function with the other, LabVIEW does not maintain the same element names.
These function names create undue confusion. Every semester, new students to LabVIEW post questions on the NI and LAVA forums asking how to use these functions to open, edit or load data from an Excel file (.xls).
Unfortunately, the name spreadsheet file has become synonymous with Excel. Even experienced computer users have an expectation of some sort of intelligent file when reading the title "Read from Spreadsheet File".
These functions should really be renamed to 'Read from' and 'Write to' DSV file...
Delimiter Separator Values (wikipedia link)
This is something that isn't a huge deal, but really annoys me for some reason. I will create a constant, then change it to a control and it bends my wire that I already lined up. I would prefer that it kept the center of the control terminal in line with the wire. Admittedly, this was a bigger problem when we couldn't create a typedef from the block diagram because I was always creating a constant first on the BD, then changing to a control to make into a typedef. But, it still plagues me from time to time.
I admit, this may be unreasonable because there are plenty of times I don't want things in line from left to right, but instead put a constant above/below a terminal, case structure etc. But, I thought I'd throw it out there.
I need the IMAQ Correlate function
to work on a sub-pixel (super resolution) basis. For sub-pixel resolution capability, you will have to change the internal mathematics of this function for floating point calculations.
This function, as I am recommending for all of the Vision functions, should be made compatible with U16 image type as well. (Currently, it is only compatible with U8 image type.)
We have a Front Panel and Block Diagram for each VI.
Front Panel as of now serves two purposes:
* User interface
* Data declaration/container
EVERY time I have a VI that has user interface, I have to hide data elements (controls/indicators) that do not belong on user interface outside the front panel boundaries.
EVERY time I need to add/edit any data element I have to move the front panel to get to my hidden data. (Then you know what happens, right? You build the application, run it to find out that you forgot to shift the user interface back, and your application shows data guts of the VI instead of neatly arranged user interface portion of the front panel)
VI should have three layers:
* User interface
* Block Diagram
Then you can edit your VI's data and block diagram all you want, and never mess up your user interface.
Data elements on the data layer don't need to have all that heavy 3D graphical representation where only borders of your nested data structures take up half a screen.
Each data element may or may not have graphical representation on user interface.
What do you think?
With using of
„\vi.lib\picture\bmp.llb\Read BMP File.vi”,
it is not possible to load a BMP file with negative height in BMP header. VI returns an error. Please update “Read BMP File.vi” to support complete BMP standard. Negative height in BMP header meaning that the bitmap is a "top-down" bitmap (the image data starting with the top pixel and end with the bottom pixel). Attached is one such image.