Corrupt glyph .png's can and do cause all glyphs in icon editor to become invisible, or maybe produce other symptoms. The user then looks in many places and eventually fixes the problem by some kind of reinitialization or synching, but the underlying issue is not understood.
In a mature feature like glyphs I would expect a check-on-load action that would report corrupt files and save (some) users lots of effort.
I know the title doesn't make sense, so I will try to explain.
I think it would be a good idea to have a way to define values similar to the C instruction #define. In C code, you can define constants and change its values all over the code during development time.
Right now, there is nothing like this in LabVIEW. You can use controls and variables, or controls and property nodes.
(Strict) Type Defs for controls have kind of the same philosophy, you change things on a single file, while all the instances are updated (but there is no way to define a single value for all the instances of a control). I guess in LV it would make sense if we could define a constant file, and place it in every block diagram that we want to get that value.
Don't you think it would be a good idea?
I tried to define a Strict Type Def with a range where only one value is possible, and the coercing options. Anyway, the behaviour is not what I expected, as it seems that the control doesn't look at its own properties until you try to change its value. If the control has a default value of 4, and you change the valid range to [5,5], the control will have the 4 value until you try to change it (and then the value will be coerced to 5).
I don't think that is a good behaviour, do you agree?
PS: I think it would be great to have a "User Defined Type Def", in which you could define the things that stay the same and the thing that doesn't, but I know that idea is not mine .
I'm growing increasingly tired og all the clicking in the BD to configure all our nodes and structures, and am searching for better ways the IDE could help us get (or get rid of) the items or settings we want. One category of configuration is our structures, for instance the For-, While-, and Timed loops. So this idea covers a couple of changes to those structures:
1) I suggest it should be possible to hide the iterator terminal in loop structures. There's no law that says it must remain present, in case we don't need it.
2) I suggest two easy ways to hide optional terminals (the iterator terminal in general and the conditional terminal in For-loops), namely selecting a terminal and pressing DELETE should hide the terminal, and dragging a terminal outside the structure and letting go of it should also hide it;
3) Making a terminal visible again should also be simpler than right-clicking and enabling the correct option in the context menu (that option should still exist of course, as it remains a standard way to find stuff if you don't know a better way). I suggest one or more "selection areas" be defined along the border of the structure, which upon mouse entry would popup a terminal you could drag back and drop into the structure. In a For-loop such a "selection area" could be the lower right corner, of course not overlapping the resize handle:
When you move your mouse into such an area a selection menu should appear, from which you can drag stuff or enable a setting or whatever:
The "selection area" should be relatively small so you don't activate it all the time by accident, but large enough that it's easy to hit. You should also be able to dismiss the popup with ESC or CTRL in case you wanted to do something else in that area of the structure.
Isn't this easier than clicking and navigating into nested menus all the time? Even the "Visible" context menu could be such a hover and enable/disable bubble...
The upcoming GPU Analysis Toolkit that calls CUDA
and the CLoo4Labview that calls OpenCL http://lavag.org/topic/13342-get-a-cloo4labview-op
I would like LV not only to let me deploy into GPU as they deploy into FPGA, I would like LV compiler to automatically find the available resources and make the best use of them.
Moving out some parallel computations from the CPU to the GPU should be done automatically behind the scene.
The prevalence of systems with more than one display suggests the addition of a "monitor" input to the unused terminal on the connector of the File Dialog function. This U16 input should allow developers to specify a display using the VI Front Panel Window:Monitor property. In addition, this function should appear on the Advanced File Functions subpalette. The File Dialog express VI should be promoted to the File I/O palette.
We update software often. Sometimes we need to know which version and build a customer is using.
My executable should be able to fetch that number when it starts up and add it to the Help/About... menu item or display it at the top of the Panel.
When building a LabVIEW executable, the build system knows that version/build number.
Let it format those numbers into a string and write it out to a dedicated textfile or add it to the .INI file.
Then when my executable runs, it can fetch and expose that number as needed.
There are some dialog boxes in LabVIEW that I think need to have a "set as defaults" option available. As an example, there are a lot of form fields when building installers for my applications that need to always be the same (or almost always). In particular the "Version Information" section:
This is something that is rather minor. However, as a day-to-day LabVIEW developers, filling these fields out over-and-over again has gotten old. Thanks for your consideration.
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.
This is a bit nitpicky, but I'm submitting it anyway because it is probably very easy to implement, has no drawbacks I can think of, and should have no implications of feature collision.
It would be very nice if there were some kind subtle indicator on the (higher level) block diagram telling you that the subVI's BD will not be visible for learning, modification, or probing. It's not a huge deal to just hit escape and then control+w to go back, but I've been doing this hundreds of times recently, having been inspired to dig through much of vi.lib after reading Darren's weekly Graphical Morsels column.
Hmmm, actually now that I'm putting the graphic together, it's not quite as trivial a choice as I first thought ... how to indicate this without interfering with the wire terminals, not adding clutter somewhere else.
The lower right hand corner seems to be the least busy place of most VI's. The graphic attached would be better if I took the effort to make the key graphic have a transparent background.
Maybe the little key icon should only show up when the user is mousing over the subVI node.
PS Just in case you were wondering, I did not make it a resolution to be as petty as possible in 2011. Pure coincidence on timing.
For the moment the INI file is managed as global feature (Link in the executable : Link to Labview.ini by default )
I think the INI keys are part of the project.
So it would be more "User Friendly" to be able to edit them as "Project properties". (Like conditional disable symbols)
Associated directly the INI keys to the project will avoid to lost important part of your application.
For example the key "useLocaleDecimalPt" is usefull when you want to force the decimal point to ".".
This is usefull when you use "Instrument drivers" which are decimal point dependant ... but don't alert when the active decimal point is ','.
I think that ini keys are part of the source code. So theire place is in the project, as project properties ... (Not globaly managed in the Labview directory)
I think that adding INI keys to the project will limit the problem of "source lost" when you many personns works on the same project ...
Or when you had to modify an old project on a new installed PC.
For the moment, I create my own local INI File in my project ... but it is not user friendly, it's manual !
It would be nice to have an option to "Refresh User.lib" folder without having to restart LabVIEW to save some time required for a LabVIEW restart.
It should be nice to be able to create a "typedef enum" for the pages of a tabcontrol ...
So the modification of a tabPage label could be automaticaly propagated to constants ..
The problem is ... When you modify the pages labels, and if you use the constant value associated with the pages ...
The associated wires are then brocken ... They are not automatically modified
When you only want to modify the Label of a tabPage (For example to correct a mistake), the Vi will no more work !
An other idea would be to add a kind of "Caption" to the tabPages, in order to disociate the 'Display name' and the Variable name ...
Here a short example ...
Other Idea : (From the well known Roms)
It should be nice to create the TabPages of a TabControl automaticaty from a typedef enum, and keep the link between the two items.
=> Modification of the TabPages modifies the typedef enum
=> Modification of the typedef Enum, modifies the TabControl content
One of the nice features in the last few versions of LabVIEW is the Shared Variable. Unlike global variables, they can be programmatically created, which would appear to open up a range of new applications for LabVIEW.
Unfortunately, they cannot be assigned default values unless the customer purchases the onerously expensive DSC module. Making matters worse, there is a run-time license associated with distributed copies of an application which uses the DSC.
Naturally, this severely limits the usefulness of shared variables.
This is not the first time that we have seen NI take a key feature which a customer would expect to be part of the PDS, and put it into an optional module. I'm sure that this is intended to “encourage” customers to purchase optional modules.
Our corporate experience has been the opposite - we have seen one of our clients blacklist NI as a supplier, after they were burned by another instance of NI's callous feature bundling.
When I change Y-Axes propertys the layout of two or more axis crashes in that way that the distance between graph and the axis is not in the right way or two axis are at the same position. In that case I have to end my application and reset the layout by right clicking context menu and do the advanced function "Reset scale layout".
The idea is, doing this programmatically inside my application. Currently I do not have a chance to do it.
Allow the Select comparison function to accept an array as its S Select input. This would allow the result of an array comparison to be followed by the Select function and if that array were then wired to one of the Select T or F, would allow each array element to then be replaced individually based on the separate boolean result. One of the Select input (T/F) would be allowed to be a scalar so the array element could be replaced by that one value if desired. This capability would provide an alternative to performing this operation with a For Loop and take up less diagram space.
This idea would only be useful in situations where the event data node is unused. There are times when we have an event but do not use the event data node. In these situations, the node takes up space.
The proposed idea is to make the event data node hideable. The little dark rectangle can still be left there so that clicking or dragging on it makes the node visible.
This is a wish.
Please NI, make the Application Builder multi-core capable. When I build apps, I see my CPU usage nailed to one core only. I have multiple cores, please feel free to use them.
I don't want my builds now, I want them yesterday ;-)
When you open an existing VI, the FP is linked with Windows as the window before the BD. When you create a new VI, this is reversed.
It sounds nitpicky, but it can slow me down a little bit when I have 20+ VI's open.
I actually immediately save and close a VI every time I create one because of this, and then re-open to get the ordering I want.