Many of us would have experienced situation where we would like to have listbox indicator or control as opposed to using array of cluster. For eg.
This is achieveable with the help of array of clusters containing different control.
To some extent dropdown menus can be implemented in listbox, but with with large and complex codes with property nodes.
It would be great to have listbox control / indicator which would be simple to use like cluster element; as in below.
Such a listbox element is very useful in product testing application.
Yup, Upgrading LabVIEW versions takes a day.
The "Process" today is:
Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......
"MyLabVIEW" would find all of those customizations and import them to the new version!
When working with large projects with many VIs I often find myself rewriting portions of the 'find and replace' feature that already exists as part of my VI Analzyer for overnight code-checks on the server...
It would be really neat if the existing find and replace logic available via the dialog was wrapped up into some simple API to allow for searching:
if it had parameters to suppress dialog popups for passwords & not-found-subVIs, that would be really helpful for running searches headlessly.
The API could return just a 1D array of paths to SubVI's where instances were found, or if it was really nice, the VI references? I'd be content if just the 'find' side of the equation was implemented..I could take any manipulations from there. I can see that there might be a dependency on VI Scripting to accomplish the search, and I'd be OK with an API that only works on a machine with a dev license... Especially if the 'replace' side of things was implemented somehow...
If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.
Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.
The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.
This is a rather non-technical request. When classes are created from Project Explorer, a color is assigned by default. If that's a color you're fine with, you hastily modify the icon and move on to more important matters.
While the color assignment works well enough to serve its mundane purpose, I've noticed several weaknesses:
My suggestion is this, and maybe there's a better way to do this:
In the class properties dialog, why not allow the user to simultaneously assign a color scheme to the icon and the class private data ("cube") icon, in one quick step?
This would adjust the hue of the "cube" icon and the VI Icon Template at the same time. It could also optionally modify the wire color accordingly.
Leave everything else on the UI as it is - this would be a new feature in addition to that pre-existing methodogy.
Thank you as always,
Note: For the sake of simplicity I chose the color picker dialog that LabVIEW uses everywhere else. Any of several other methods could be used, such as a pulldown menu with predefined color names and swatches. (Say, a dozen selections)
Related ideas I came across:
When I try to pull a BIGINT value from a SQL database with the Database Toolkit the variant that is returned apparently does not have the value from the database. I say apparently because if you convert that variant to a string you get the data.
My issue is that when the data is in variant format it looks like the data is gone. I think that the value should be displayed to avoid errorneous thinking that there is a problem with my SQL query. This is very misleading and I think the variant value and the string values should match. Otherwise, it looks like there is an issue with my SQL statement.
Here is a screen shot of my code in which this occurs:
What I'm asking for is an optional indication of reentrancy in the context help window.
This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.
I realize that Greg Freeman suggested something similar. My intent here is to narrow down several ideas from that conversation down to a single suggestion.
(I hope I still didn't manage to post a duplicate. Apologies if I did.)
While some ideas like this suggest that we should be able to open block diagrams without opening the front panels, and others suggest that we let go of the front panel as the primary part of a vi, the front panels will probably be around for quite some while yet. But the block diagram is where we primarily work, and closing a vi requires clicks on two different windows. Using ctrl+w twice is not working since the second last window is not always the FP (if it's your very large project this may be annoying).
Let us have the possibility to close the entire vi including FP from the BD by ctrl+click the panel close 'x'. Similarly, remap ctrl+shift+w to close the entire vi.
Would it make sense for the "Save All (This Project)" menu option to appear on all VIs that are members of a project? Obviously it's on the Project Explorer window, but it's not on the VI panel or diagram windows.
I noticed that I frequently (subconsciously) select "Save All" from a VI's panel or diagram, only to get warnings that another project I have open is read only due to source control. Sometimes my Project Explorer window is buried under several other windows, and it's nice to be able to quickly save the whole project.
If I've missed something obvious or there's a good reason for this feature not to exist, I'm all ears.
I had posted this same idea in another post but it didn't have enough clarity and was mostly misleading the forum members. I was not able to edit it that I had to post this in a new thread here.
I felt that it would be good to have an option to switch to the last visited case in a case structure with numerous cases when going through the cases for debugging or understanding a code. It often happens that I have to scroll through the list of cases to get to a case and then may be I'll have to check something in the top most case. Again if I have to check the last visited case, I have to again scroll all the way down to the case, which becomes a little tedious. Instead, it would have been good if we had some kind of option to switch to the last visited cases sequentially (in a right click menu of the case structure or some keyboard shortcut after selecting the case structure).
I'm sorry if someone has already posted this in the idea exchange forum. I tried to search it but couldn't find any such posts.
I suggest adding a jog-wheel (unlimited range knob) to the palettes:
The current knob you set the minimum and maximum range, and can then select inbetween those values by turning the knob from one endpoint to the other.
A jog-wheel you configure with only the range for one complete revolution of the knob, but you will then be able to turn it as many revolutions as you wish and it'll continue to increase or decrease its value (depending on if you turn it CW or CCW). This'll work like the jog-wheel on a video-player; configure it for a range of 10/revolution for instance, if you then want to move 30 upwards, you just turn the knob three full revolutions CW. It should support the mouse scroll wheel on top of it of course, for "quick jogging".
The LabVIEW menu has two entries with somewhat overlapping functionality that can lead to confusion
(1) "New..." let's us create many new things, from a blank VI to complicated design patterns and project templates.
(2) "Create Project ..." lets us create a new project using a wizard.
Since the results of menu (2) is invariably something "new" too, it seems odd to have things scattered across two different menu items. I think the "New..." dialog should simply add all the "create project" items under the "project" category. (e.g. "new project using a wizard" or similar.).
(Case in point: I recently attended a myRIO hands-on seminar and was looking for the myRIO template wizard in the "New...." dialog by accident. While there were some other myRIO related projects listed, I could not find what I needed until I looked in the "Create Project..." area. Very confusing!)
I find myself making a lot of VIPM packages for code re-use. As we re-use more code we increasingly want to protect the code so that we can more freely share such packages with e.g. sub-contractors/licensed users without sharing the block diagram. (and the first person to suggest we use VI password protection gets to wear the donkey ears for the rest of the year.)
When you remove the block diagram from a VI, you also remove the ability for that VI to recompile which means that it can only run on the same version of LabVIEW and on the same hardware as it was compiled on/for. This makes it a giant pita if you have code that is used (and works) equvally well on e.g. vxWORKS cRIO and "Windows". Currently VI's consist of 4 parts (Front panel, block diagram, code and data) and without the block diagram, the code section cannot be recompiled.
I wonder, if it would be possible to extend this to either allow the "code" section of the file to be essentially an "array" or at the very least let there be two "code" sections? -It would tremendously increase the usability of the "remove block diagram" feature if we didn't need to maintain a copy for each hardware platform.
I'm not sure how technically possible this would be, but since deployed code (at least to RT) typically gets compiled into (rt)exe's the extra and un-used code section(s) could be stripped during exe build, and the slight performance hit during development/debugging runs that might come from this along with larger VI size seems to me to be a decent trade-off.
So my suggestion is to investigate this and if possible allow some extra choices during the "strip block diagram" from VI process where you get to select an extra "target platform" or two.
A much less savy alternative would be to modify the existing tool to automatically pre-fix and output multiple "versions" of the same code distribution, one for each selected target platform. This would at least speed up the process of maintaining and creating all the variations.
I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.
As mentioned above, LabVIEW should add an Options>>Block Diagram or Environment setting of "Name Format" for property nodes. Currently you start off with short names (default) or whatever the previous designer of the VI set as the name format of a specific property node. This can lead to confusion if you are used to seeing it one way or the other; and it can be annoying if you want to change the name format of all property nodes in a VI.
LabVIEW should have four options to select as default.
Listed below is an example of the different "Name Format"s of the same property node.
This should be an item in Options as shown below.
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
Connecting to remote panels using LabVIEW is difficult if private networks, local private and external public IPs (under NAT), and firewalls, etc. are involved. It requires significant knowledge as well as external networking configurations (port forwarding, etc.), and possibly admin privileges to modify those.
There are plenty of companies that have found a way around all this. The prime example is chrome remote desktop, which seamlessly works even if target computers are in hidden locations on private networks, as long as each machine can access the internet with an outgoing UDP connection. The way I understand it, each computer registers with the Google server, which in turn patches the two outgoing connections together in a way that both will communicate directly afterwards. All traffic tunnels inside the plain Google chat protocol (udp based). Similar mechanisms have been developed for security systems (example) and many more.
Since the bulk of the traffic is directly between the endpoints, the traffic load on the external connection management server is very minimal. It simply keeps an updated list of active nodes and handles the patching if requested.
I envision a very similar mechanism where LabVIEW users can associate all their applications and distributed computers with a given user ID (e.g. ni profile), and, at all times be able to get a list of all currently running remote systems published under that user ID. If we want to connect to one of them, the connection server would patch things together without the need of any networking configuration. Optionally, users could publish any given panel under a public key, that can be distributed to allow public connections by any other LabVIEW user.
This is a very general idea. Details of the best implementation would need to be worked out. Thanks for voting!
Currently we have File >> Save then File >> Apply Changes.
I would like save and apply changes for typedefs in one operation. So either replace Apply Changes with Save and Apply Changes or add this as another option to the menu.