When using dll's or .Net assemblies, you always have to right click & hunt down which version gets used for the constructor.
It'd be handy to have the version shown in the Help. I already know it's a constructor node, that's not much help...
While creating a sub vi mostly I don't bother about how the front panel looks and also while coding its easy to take the constants from the function palette. What we will do if we need a control in the block diagram.
Method 1: Select a constant and then convert that into a control
Method 2: Go to the front panel and place the control that is required.
Instead of doing these things it would be best to be able to place a Control in the Block diagram (Even the error clusters). This may be implemented by
Right click mouse to launch Function palette --> Place the mouse pointer over the contant --> Press CTRL and Drag the constant to the Block Diagram. Control is created. I was having this in mind for a long time but not able to post. I am not sure whether it has been already posted.
Idea Subject really describes it.
Property nodes should allow arrays of references on the input so that the same property (i.e. disabled) can be applied to multiple controls without needing a for loop.
Errors could be handled much the same way as compound property nodes are now, ie with the option to ignore errors within the node. I imagine most errors would occur during development time anyway.
In the 'Source File Settings' category of the 'Build Specifications' dialog one has the option of customizing the destinations of the elements of the build. One very handy feature here is that it is possible to set the destination for all elements contained in a folder (virtual or auto-populating).
In the project tree Libraries, Classes and Xcontrols act like folders in that they have a parent item containing child items. Unfortunately the 'Set destination for all contained items' feature is not implemented for these parent items.
A work-around is to put the class/library/xcontrol in a folder and then set the destination for the folder but that makes the project look very messy.
Here are some pictures:
I love the new quickdrop plugins! I've written a few that I use all the time. (Reset front panel to origin, emergency abort vis, etc.) The only thing I don't like is the requirement to name the plugin the same as the letter that will activate it. Since my 'q' plugin and 'shft-q' plugin have to reside in the same vi, it is a bit harder to share plugins with others.
I would like to have the ability to give the plugins a descriptive name and have a configuration utility where I can assign hotkey combinations to each of my plugins.
In "Image Displays", Images are locked in the center position when the area is bigger than the image. Could we have more control onver their position ?
This feature would be useful for those who need to show images with different sizes in the same "Image Display" (not simultaneously).
I guess a new ImaqImage property like "center position" or "top left corner position" or "alignment" would be enough ?
In short: please show scrollbars on palettes in edit mode, allow us to resize the window - and autoarrange the items to fit in the new window frame - AND make it possible to select multiple items and drag & drop them to new locations on the palette.
My user palette in particular has a tendency to grow very large and untidy. In normal use you get scrollbars that allow you to navigate through large palettes, however if you want to arrange the items in a palette and go into edit mode you end up with a palette that spans several screens - with no option to resize it or scroll through it. Instead you have to move one item at a time, empty a row, delete it...and move you way meticously through it. There is no drag and drop support (well, unless you count the option you have if you select move from the contextual menu first, one item at a time), auto-arrange, or window scaling options.
Sure, you do not need to do this very often (although I often tend to repeat it after upgrading LV, which now means once a year...) - but that does not mean it should be allowed such a crippled user interface.
A summary of the issues is shown on the picture above.
The idea is to be able to replace wires running across a case structure with terminals that take the connection on the left side and connect it to the right side. I would think the left side should allow a through wire for reading variables, but the right side should not, as then the jumping structure wouldn't really be needed. This is something that would be specific then to that case or entry in the structure, and not the structure itself.
I use this dialog a lot and would like the following improvements please....
Split Found In data into Found In and Type
Make these columns sortable.
This would allow me to quickly filter out innapplicable results, while we're at it can I have a search within results options too.
Kudos the hell out of this one please.
Many Thanks and Much Love
When you have a lot of cases (or events) in your case (or event) structure it can be tedious to go back and forth between them (yes, Ctrl + Mouse wheel works great but can be hit and miss to get to the right one that is many cases away). Often times I am in one case, I need to grab/do/look at something in another case and then return to the case I am working on. It would be nice to have a Back and Forward button (similar to a web browser) so after I can quickly jump back to where I was. The only way to do it now is to click on the case titles, scroll up/down (which can be very tedious if you have enough cases that it goes off-screen) to switch between.
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?
I'd really like the blackened left-upper corner that you see on control icons to also be present on refnums if they point to a control that is a typedef...
This has the additional benefit (besides just being helpful) of letting you know if you accidentally diconnected the typedef and the refnum is no longer typedef-constrained...
Basically this would take effect when you drop a typedef'd control on the refnum...
It would be nice if it was possible to create a empty folder with the installer.
I have an application to handle some files that are generated by other applications. Therefore I require that there is some specific folders which these programs can place their files in.
I know I can create them by placing a dummy file in the created folders, but I think it is a mess with non relevant files.
Since the Actor Framework came up, I'm getting more and more into object oriented programming with LabVIEW. But I'm missing one of the biggest strengths of LabVIEW with it:
The ease of bounding your source code with a graphical user interface.
When you create a front panel object from a class object you can neither display nor control data. You can just display the object icon. So this is basically the flipside of the “Cluster as Icon on Front Panel” request. Instead of an icon I want to have my object’s private data in my front panel. So a right click -> show private data would be nice:
This would become handy not only for creating user interfaces but also for debugging, since the probe is often difficult to overview when you are dealing with data strucutres like arrays, clusters and objects.
Right now the workaround is to create a cluster type def and put the cluster into the private data. But this is unhandy. Instead switching back and forth between icon and data, you have to bundle/unbundle and create control/indicator. You have the additional file in your class. And you have the "additional bundle/unbundle mouse maneuver" if you want to access single elements.
So I was looking at the idea submitted "Remove Common Error Functionality From Set/Unset Busy Cursor" and I came up with a more useful, and more generic way of dealing with that problem, and the problem of 'anchoring' code for flow-of-control in general.
I too use flat sequence structures to force flow-of-control, and there should be a better way. There is.
Suppose we simply add 'ignore error' functionality to the error-in/error-out terminals? In that manner you could create a vi just the way that you do now, with error in/out, but by right-clicking on error-in and selecting 'ignore error' the following would happen:
1. The VI would ignore a pre-existing error. It would run as if no error was present on error-in.
2. The error-in terminal would change color (or shape, or size, or relgion) so that it was visually obvious that the 'ignore error' functionality was enabled.
3. The error code passed to the VI, although ignored within the VI, would still be passed thru to error-out.
4. If the VI that was called with 'ignore error' generated an error, that error would still be added to the error codes output.
This hasTWO major benefits: (1) it provides a super simple way to create VI's that need to execute in order but don't need/want error functionality, without requiring the user to add unnecessary objects (like flat sequences) or write special code to use it; and (2) it allows you to write routines that should run regardless of whether an error is present or not, but still allows them to post an (additional) error if they need to.
In existing "File Dialog" Express VI- configuration Dialog we can specify what we want to select(File/Folder), wheather its new or existing File etc.
However for specifying File Pattern, Pattern Lable, Dialog name etc. we must connect constants from outside. it takes lot of space.
it would be great if those options can be configured from pop up.