Pretty simple idea. When you are creating installers, you are allowed to install files in many different locations. Including lots of system locations.
But for some reason, Public Documents is not one of these destinations. It should be.
Because its not in the list, I need to go through some annoying workarounds which I don't totally trust.
It would open a copy of the project that has been copied to a user selected directory along with all its dependencies.
The same thing can be accomplished by immediately doing a Save As>>Duplicate .lvproj>Include All Dependencies. But I have on several occasions "checked something really quick" only to come back to a modified example I didn't realize I modified.
In addition to making this very common copy operation simpler, it would be a nod to new labview users that they need to create copies of examples before modifying them.
There are a plethora of timestamp formats used by various operating systems and applications. The 1588 internet time protocol itself lists several. Windows is different from various flavors of Linux, and Excel is very different from about all of them. Then there are the details of daylight savings time, leap years, etc. LabVIEW contains all the tools to convert from one of these formats to another, but getting it right can be difficult. I propose a simple primitive to do this conversion. It would need to be polymorphic to handle the different data types that timestamps can take. This should only handle numeric data types, such as the numeric Excel timestamp (a double) or a Linux timestamp (an integer). Text-based timestamps are already handled fairly well. Inputs would be timestamp, input format type, output format type, and error. Outputs would be resultant format and error.
Similar to 'Insert' and 'Delete' methods, please include 'Transpose Array' method as shown below:
The In Place Element (IPE) is great and so are Data Value References (DVRs).... but... well sometimes I'm not such a great programmer and I will cause a dead lock in my code causing what looks like a "hang". Debugging can be hard in that case when trying to figure out which vi was trying to access the DVR. Also if I'm using the dvr for some sort of global storage, i may want an error to ocurr if some piece of code holds onto the DVR lock for too long.
I'd love for the IPE to have a timeout when you have 1 or more DVRs and if ALL of the references are not available in the specified time, the structure returns an error.
On downloading a file from internet and if the file already exists (file with the same name), it automatically appends an auto-incrementing number to the file name, wouldn't be it nice to have the similar feature (may be optional) with Open/Create/Replace File Function.
Consider the scenario, you've enabled this option ('append number if file already exists' as shown in above figure) while using Open/Create/Replace File Function and operation input is 'create' and name of the file is MyFile.txt, which already exists then this fuction should create a new file with name MyFile (1).txt (or may be MyFile (2).txt if MyFile (1).txt also exists and so on).
Right now, if you select to show the label of a wire connected to the output of a named cluster, the label is empty:
The white space surrounded by a box pointed to by the line is the location of the blinking cursor.
This is similar for all wire sources: controls, constants, function outputs, etc and should behave similarly for all.
For reasons outlined in detail in this idea, the the expression node should be redesigned. These vertical lines are too thick and the end arrows are pointless and too busy.
After all, the expression node is basically a [single line|single variable] formula node and for this reason it should look more similar to a formula node.
Here is my suggestion for the redesigned expression node (on the right). The current design is shown on the left for comparison.
Note that the grey left and right borders are exactly matched to the border design of the formula node, making things consistent and intuitive. (Top and bottom should remain single pixel to save diagram space).
Right-Clicking on a connector in the connector pane brings up a context menu. This menu should have the same "Find Terminal" option as if you click on the FP object. This will provide quick access to the Terminal especially if the FP object is hidden.
When I duplicate a VI inside a library or class using Save As... and check the option to add the duplicated VI to the class/library I would like the new VI to be placed in the same virtual folder as the original. I will settle for what I asked for in the title, an additional option to perform the same.
This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.
To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.
Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.
My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.
Typical phone exchange yesterday:
me: "just click my installer and install the program"
him: "OK, done."
me: "now run it."
him: "OK, ...... error about 2013 run-time engine".
me: "OK, install the run-time engine using the link I sent you in the same e-mail".
him: "clicking the link to go to the run time engine page....
(..30 second discussion to decide between downloader and direct download...)"
him: "click..(wait for it!)... .it wants me to register..."
me: "OK, let's forget about that. come down to the lab and I will do it for you."
End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.
While gazillions () of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.
I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to " I don't want to register at this time, just download the run-time!".
Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers.
Suggestion: Double clicking a connected terminal on the connector pane highlights and jumps to the connected control. This would be useful for controls that are off screen or hidden.
Similar behavior to double clicking the associated terminal/icon on the block diagram, where it automatically repositions the front panel's view.
I suggest that they are made to look different so we can tell immediately what we have.
For example the two results below are very different, even though the code looks absolutely identical if the labels are hidden.
One possibility would be to make "convert unit" a different default background color (example shown below), but there are probably even better suggestions. How about rounded corners (not shown)?
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!
I thought this feature existed and this led to this aborted bug report.
Oftentime, I find myself needing to create a control (or an indicator) on a subVI so that I can connect a block diagram object to the subVI.
The object can be a constant, a local or global variable, or of course a terminal.
Right now, selecting and copying the BD object and going to the subVI's FP and trying to paste the object results in nothing, unless it is a constant.
You have to go into the subVI's BD, paste the object (which, if you have selected a local variable, will become a terminal), double-click the terminal to switch to the FP and then manipulate this control/indicator (in my case, connect to the connector pane):
Step 1: Source BD
<---- select the terminal and copy it
Step 2: Target FP
<---------Oops, that's right, nothing happens if I try to paste it directly on the FP...
Step 3: Target BD
<----- The terminal is pasted fine on the BD, but that's not where I want to work
Step 4: Go and find the Control on the FP and bring it back where you really want it!
The problem with that approach is that LabVIEW is none too clever in terms of placing a FP object created from the BD.
If your subVI happens to be a carefully layed out UI, the new control might be dropped outside the visible area, and double-clicking the terminal to get to the control/indicator will move the visible part of the FP in order for the control to be visible.
It would be preferable to drop the newly created control precisely where you want it to be, hence the idea to bypass the BD altogether.
When configuring a type specifier for Open VI Reference so I can run Start Asynchronous Call, I drag a VI onto a type specifier VI Refnum.
If the pinout of that VI changes at all - even if the only change is to add an item to an enum - the call to Start Asynchronous Call breaks, because the types no longer match.
When configuring a type specifier (constant, control or indicator), I can maintain the link to the source VI, so if the pinout of that VI changes in any way, the type specifier doesn't have to be manually modified. In essence, I want an "Auto-update from type definition" option for type specifiers, with the VI as the type definition.
Currently, the VariantDataType are buried deep in VI lib but they are very useful when trying to program based on datatype. Can we bring some of those functions into the light?
The configuration panel of express VIs has the [X] disabled in the upper right, but contains standard [OK], [Cancel] and [help] buttons.
Every computer users is familiar with the function of the window close button [X], and for convenience it should be enabled unless there is a very good reason to disable it. Such a reason does not exist for express VI panels. Pressing the [X] should act indentically to pressing the [Cancel] button. Note that even the <esc> key is already bound to the cancel button as it should!
So why is [X] disabled? This is unecessary micromanagement of the user! Do it like this, not like that!!! (slap on the hand!)
Users should have all intuitive and typical methods available to cancel out of an express dialog:
The configuration panel of express VIs should have the windows "close" button ([X] in the upper right) enabled and when pressed, it should act identically to the [Cancel] button on the panel.
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.
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.)