I find that changing of the color of the axis name to be different than changing the colors of any other items on the axis of a graph or chart as well as less intuitive and more mouse intensive. If the ability were on the Scale page of the Properties, it would be with the rest of the axis Scale color boxes.
Here is the current Scale page of the Properties dialog box for a graph:
So you can adjust the colors of the scaling like so:
But the only way to then change the color of the axis name to match the scale colors is to highlight the entire text box, click on the Font drop-down box, slide to Color and then slide to your color without moving the cursor outside of the drop-down box because then you get to start over at the drop-down box. This is a lot of mouse movement when you have three or four different plots that you want to have unique colors.
A better way would be to have a selection for the color right on that properties page like so:
It doesn’t matter if it’s in that spot exactly or with the rest of the color selector boxes in the Scale Style and Colors section. But I believe it would make sense for it to be on that page.
I think everyone's been there before.
Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code. Not a nice thing to have happen.
At the moment, it's quite a nasty job trying to track these things down. Usually most users resort to trial and error in trying to find the culprit. I myself use the mass compile function to at least narrow down which files have the problems. Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.
I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this. I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier. How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.
I'd love it if the LabVIEW developers optimized the search speed for searching pallettes for VIs. When I hit the Search button on the Controls pallette, it can take 30 seconds or more before I can search as it says "Populating List...Please Wait." It would be great if LabVIEW could populate the list as a background task sometime after startup such that when we need this function it would be ready to go without waiting.
A while back, Dany Allard suggested merge and diff tools for projects and libraries. I have a request that is similar, but more specific:
When opening a project, if for various reasons LabVIEW is unable to locate dependencies of a build specification, it would be truly helpful if the user was prompted to locate said dependencies. As it stands, by my observation LabVIEW silently omits missing build spec dependencies - this can be frustrating and dangerous.
Here's some context: I have lots of projects with 5+ build specifications. When I move directories, files, or even change LabVIEW versions, my build specifications stealthily fall apart, sometimes very subtly. Often I don't realize that my build spec is broken until I attempt to build, only to realize that it's a hollow placeholder in my project file. The most insidious case is when the application builds successfully, but is missing dynamic VIs, etc. This omission might go completely unnoticed without rigorous testing. LabVIEW should, in my opinion, give the user some indication that the build specification is missing dependencies or is "broken."
One hypothetical way to indicate this status might be to list the build spec in red font within Project Explorer, and have dependencies listed in dimmed font within respective build spec dialogs. There ought to be a "resolve conflicts" button in the build spec dialog; Perhaps this functionality could be integrated in the main conflict resolution dialog somehow.
Furthermore, there ought to be an option to import build specs from other projects. (Okay, maybe this should be a separate request) When importing, the aforementioned conflict resolution process should be leveraged to make the import proceed smoothly.
Has this already been requested? Thanks for listening.
Sometimes when searching, certain subVI's take forever to get through, and they're almost never what I'm interested in searching. A simple checkbox in the VI properties that said something like "Skip this VI when searching" would fix this neatly.
(slight aside, two of the slow ones have a bunch of .NET calls in them)
The only other way I know of to accomplish something similar is to password protect the slow VI's, but I work on a team and that would be a hassle for everyone.
This is related to the following suggestion, which is to allow multiple search windows to be open. If that were implemented, it would at least make the slow searching less painful, by letting me keep previous results. But I often end up wiping out the search results by doing something like 'find all instances', and then I'm back to the slow search.
1) I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes
2) A shortcut to make the selected "control label" in the front panel or block diagram to make it BOLD. (CTRL+SHIFT+B) or anything equivalent
I create a new project and go to save it for the first time. When I chose a location to save my project, I want it to create a folder for all the project files at that location. Instead, it asks where I want to save the .lvprj file and saves that as well as two other files (.lvps and .aliases).
From my experience with other programming languages and development environments, I think it’s pretty standard to automatically create a project directory (in a folder) when you create and save a new project.
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.
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.
Currently when a vi is called asynchronously, it will live - even when the calling VI stops. This may cause problems in some cases - for example, code that uses the "first call" function. During development, it is not unusual to have a VI stop inadvertantly without proper cleanup. With Asynchronous VIs running in the background, you must shutdown and restart your project to clear out these Asynch VIs. It would be nice to have an option on the OpenVI function that caused the Asynch VIs to abort in the event that the calling VI shuts down inadvertantly.
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...
Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.
I'd like to suggest some improvements to the run-time menu editor dialog: (This is found under Edit->Run-Time Menu...)
1. Allow the window to be resizable. (Scroll bars are no fun)
2. When using source control (Perforce in my case), prompt the user to check out the .rtm file upon the first edit. (Same behavior as when editing VIs) At present, if I forget to check out the menu file I get a very ugly dialog followed by an "Emergency Backup Destination" prompt. [insert muttering of naughty words]
I'm then faced with two choices: Either I can save an "emergency backup," as the prompt refers to it, or lose all of my changes and edit my menu all over again.
3. The manner in which the tree manipulation works seems kind of wonky to me. I've been using it for a long time, but I'm getting to the point where I stop and ask, "Why does it do that?" For instance:
Let's say I select the root node of my "Edit" menu which has several items under it, and I've got that menu open. If I press the yellow, down arrow, the whole Edit menu relocates itself under my File menu. The file menu is above the Edit menu! Why does pressing "down" move the menu up? Intuitively, I'd expect the entire Edit menu to move as a unit and appear after my View menu, exactly as it would if the whole "Edit" subtree was closed. (This is hard to explain and I understand if my explanation is likely confusing.)
4. When dragging and dropping tree nodes, there's no visual cue as to where the item will land. You start dragging the node, mouse over the general area and cross your fingers. Alternatively, you can eschew dragging and dropping altogether and opt for the yellow arrows of wonkiness. Okay, in fairness the arrows are usually alright.
5. I would really like to see Edit->Undo and Edit-Redo on this editor dialog. Having to revert entirely and reopen the file can be frustrating. Mistakes happen often, especially when dragging and dropping.
6. This is less important to me than the other suggestions, but... is there any reason why the menu files couldn't be encoded in XML? Right now they're not very text editor friendly.
Of course, as I offer these suggestions I intend no disrespect toward whomever developed the dialog - I'm simply perceiving room for improvement.
Thanks very much,
I was quite surprised that no one wrote a suggestion about this yet, at least I didn't find after doing a search.
Sometimes, when Highlight Execution is on, you need to see a portion of the code that is not in the screen. Doing a scroll to see the desired code, part of the code being showed goes away, with the values shown by the Highlight Execution. If you bring back that portion of the code that was on the screen originally, the Highlight Execution values will not be there. You need to wait until next turn to see new values, or put probes in the wires to see then right away. Sometimes we need to see the FP or put any other screen over the BD. The result is the same, the Highlight Execution values will be gone.
The idea is to have an option to make the Highlight Execution values stick until you turn the Highlight Execution off.
Another interesting idea is to do implement the idea above and add a button to clear the Highlight Execution values anytime you want. Then the values could remain even after the execution being stopped. The advantage of this idea is that you will be able to edit the code with the values of the last execution on. May look messy, but you just need to press the clear button and all values will be removed, not a problem. With this concept it will be easy to save a screen (print screen) with Highlight Execution values on. Probably this also reduce the amount of probes needed in a daily basis.
LabVIEW has a success story due to it's ability to program graphically. But the new LVOOP features still lacks the graphical touch. On the other hand, the text based SW is catching up with graphical modelling concepts as uml.
So instead of a simple config editor to set the inheritance, I request to have this completly graphical.
It's THE main feature of LabVIEW to do things graphically, so why fall behind this standard? No, not this tree control, but draw a wire to the parent, uml is already showing the way.
Make it possible to select several global/local/shared variables or proberty nodes and change all to read or write in one step (context menu option)
To use controls as custom probes is very helpful. But sometimes it would be good to have the possibility to adapt the custom control probe like a control on the front panel:
- changing the size of the probe control in its display pane
- changing the size of a array control to show more data elements at once