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.
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).
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.
Similar to 'Insert' and 'Delete' methods, please include 'Transpose Array' method as shown below:
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.
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.
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).
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!
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.
I propose that enum controls be more customizable such that each enum item may also be given a background color and font color to allow the items to be color-coordinated. Here is an example of what I'm wishing I could do:
Excuse the poor art, but I don't have time to make it look fancy, you get the idea. I think it's quicker and easier for people to correlate two objects by color instead of by small-print font, so when a user needs to connect a front panel control to a hardware I/O pin for example, having a color-coding scheme makes things more user-friendly. Also the first four channel colors just happen to correspond to the channel colors of my oscilloscope, another example of why this could be useful.
I realize that changing some of these colors may be possible to some extent by using property nodes, but that wouldn't work if this is control is placed into an array--changing the color of one element will alter the color of every element in the array.
I'm on LV2012, if this feature already exists in a future version then forgive me.
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.)
Right now we can make a conditional disable structure that behaves one way if we the VI is running in the Run-Time engine or not. What I think would be useful is if we could also decide on performing one case or another based on the version of the Run-Time/Development of LabVIEW.
Say I develop some neat little reuse VI that relies on getting the name of the label of data type passed in. OpenG has a functional already that does this called Get Data Name. NI has a version as well in vi.lib called GetTypeInfo.vi. The problem is in 2011 the OpenG method is about 10 times faster, but in the 2013 version the NI version is 10 times faster.
Wouldn't it be nice if a conditional disable structure could choose to do one thing over another, based on the version of LabVIEW it was being run in? This way reuse code could be written to perform best in what ever version it was running in.
There are many situations were one code written using some function either runs slower or faster in different versions of LabVIEW and using this we could choose the best option for that environment.
Of course there is a work around and that is to read the App.VersionYear property, put that into a case statement and perform different code for one version or another but this has added over head, and is called every time it is needed.
EDIT: Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.
I'd like to suggest that the error ring dialog ("Select Error") have an entry for a search expression.
For instance, I'm looking for an error code for an index out of range. I might enter, "index" or "range" as the search term, and browse the resulting error codes whose descriptions include that text.
While I don't find myself using the error ring itself very often, I do use the resulting dialog quite a bit to browse for appropriate error codes. The trouble is that there are a lot of error codes and you could be staring at them for quite a while looking for the right code.
The current behavior of the LabView development system is to raise all its open windows (VI Front panel and Block diagrams that are not minimized) when one of them attains mouse focus. This issue has be discussed previously here
The issue becomes much worse if the "focus follows mouse" mode of the operating system is activated. In this mode try to work on a non-LabView window on top of some LabView windows. As soon as you accidentally hit one of the LabView windows with the mouse, all of them pop to the foreground, eventually hiding the non-LabView window totally. This is neither necessary nor convenient!
Moreover, all suggested solution in the above links are inaceptable (e.g. minimze most VIs). I need to have open many VIs at the same time and I need to look at them, while e.g. writing documentation in MS word.
Now I hope I'm not the only person who learned to love the "focus follows mouse" mode during years of using linux.
So, to cut a long story short, I suggest to introduce a config option like "raise on focus" that toggles the behavior for all open LabView windows. I do not even ask to treat individual LabView windows differently, since I understand that this is not possible due to the internal window handling of LabView.
Thank you for reading this,