When the abort button is pressed, and the development environment is present, the block diagram should be shown and the portion of code that was currently executing should be hilited.
I've been wondering for years now why the LV Save (& Save All) dialog is quite unusual in terms of its layout & usability.
Redesign the "Save Changes?" dialogin accordance with the standard dialog design criteria as follows.
The title says it!
It is often confusing "Which is the opposite end in a queue?/What does opposite end mean?", esp for new user of LabVIEW.
Seems here, even the author of the LV Queue primitives was not able to recollect its name correctly.
Also, please see below from the LV Help.
When working with User Events as an API between modules there is a nasty little thing which unfortunately keeps rearing its ugly head.
If we retrieve a cluster of User Events (or an Event registration refnum) from a module with events we should be listening to and wire this to an event structure we get a memory leak if not all events are handled. This particularly occurs whenever the API is extended and not all listeners have been updated.
It would be much easier to track down these kinds of problems if the Event Structure would display which User Events are in the associated Registration Refnum but are NOT yet handled. This would be a great too in tracking down rogue Events and eliminating possible memory leaks due to implementation errors.
Currently one has to iterate through ALL of the user events and observe the warning "this event is handled in another case" in order to find out if all have been handled or not.
When developing new VIs f the procedure is usually the following:
1. right-click class or desired location, new VI (static or dynamic dispatch template etc.)
2. Implement functionallity
3. Edit VI icon for easier recognition
4. Save VI
The problem here is that usually the icon allready contains the ideal name for the VI which means I am typing the name of the VI twice, once when editing the the icon and once when saving.
Would it not reduce the development-time by suggesting the name entered in the VI icon editing procedure as the user attempts to save the VI?
I'm currently expanding a large SA with 270 classes and on good days I implement 20-30 VIs and would find it nice if I were not forced to type the name twice.
Interested what experienced LV-users think of this suggestion!?
The Open/Create/Replace file I/O primitive is pretty powerful. It will check to see if the file is there for you, and, if not, create a new one. I use the "Open or Create" option often when generating multiple delimited text files in long term tests. When a new file is created, I need know so I can add a header, and I need to skip the header operation if the file is being appended. Sure, I could check to see if the file exists before trying to open it, but then wouldn't that just make the power of the Open/Replace/Create function redundant? Some operation took place based on my input to the "operation" terminal, and whether or not the file exists. Unfortunately, I have no idea what that operation was, because the function doesn't tell me. Let me know if the Open/Create/Replace function created a new file so I can add my header.
This is not without precedent. For example, the "Obtain Queue" primitive has an option to create a new queue if a queue of the given name is not found. It let's you know if the new queue was created:
Right now the only way possible to set the tabbing order of controls on the front panel of a (sub)VI is to use Edit >> Set Tabbing Order.
I would like a VI Server property/method to be able to programmatically set the tabbing order of the controls on the front panel the way I want. This way I can write a script to fix a large number of VIs without needing to manually click through each one. (Of course I would be responsible for programmatically figuring out the order I wanted, but I could make some general assumptions like following the top-bottom left-right on the front panel existing layout, or following how they are connected to the connector pane, etc)
the input value of the conditional terminal should " pass through "
(like the "case selector" of the "Case Structure")
As requested by this fellow 8 years ago: http://forums.ni.com/t5/LabVIEW/Multiple-pattern-l
Currently, we get a single line:
This results in this kind of mess courtesy of the IMAQ Load Image Dialog.vi):
To update the snapshot illustrating this other thread, here is an example of MS Word in action, illustrating the desired behavior:
In other words, it helps cleaning up the results, while using a single dialog window for all kinds of different files (which will be dealt with differently down the line).
I am not sure how multiplatform that can be, but here is the file open dialog options from TextWrangler on MacOS:
so it seems that can be done.
The thread I am referring to had a link to a Windows API call, but the link is dead (probably the result of the recent disastrous site cleanup). And of course is not multiplatform.
Am I the only one that get forever waits when this dialog shows up? LabVIEW hangs "eternally" in this dialog and only way to keep working is to kill LabVIEW hard.
I need a button that skips the resetting so that I can go back to my code without having to restart LabVIEW!
When doing code refactoring (or other improvements) we often run into the situation where we may want to replace constants for whatever reason.
Example: If we previously have only had support for 8 devices which (for reasons I won't try to defend here) ends up being hard-wired into the software and we now want to change the code to replace these constants with a Sub-VI we have a very hard job finding all of the instances of "8". I can search for a numeric constant but this produces so much noise it's useless. It it were possible to narrow down the search to the value "8" for a numeric constant thent he search would be much easier.
Same goes for paths, enums, error clusters and so on.
I often get this dialog when a class is locked because a VI is still in use by some running process. It might be a reentrant process that for some reason didn't shut down as expected, but in a system with 3000 VIs and lots of asynchronous processes it can be very hard to guess what code is still running. And this dialog doesn't give much information. It would be great if this dialog could show exactly which VI (with full information of what reentrant copy of the VI it is) is still using the class/VI. Even better if you could click on the filename in the dialog to open the VI.
I feel like in a few cases, my code could be more readable, if a picture ring constant existed. By that I mean if I could have a block diagram object, that showed an image, and clicking it would allow me to select one of the other images in the ring, which correspond to a numeric value, just like the picture ring control does.
I've come into a few cases were I want to know if my picture ring on the front panel is equal to some case. So I will use the equal primitive and compare my picture ring control value to a constant. Problem is my constant is just a numeric, because that is what the data type of the picture ring is. I then usually need to put down a comment explaining what the value of 2 or 3 is supposed to be. I feel like a better solution for readability would be to have an equal function, and wired to it, is another instance of that picture ring type def, where you can see the image that the value is being compared to.
Now sure this doesn't come up often, and in most cases it is recommended you convert that ring into an enum, and then you get a bunch more benefits, but in a few cases I feel like adding a picture ring constant would only make the code more readable.
I often run into this dialog, asking if I want to continue with prompts or continue without prompts when saving all. Sometimes I want to continue with prompts because I don't want to check out (Subversion) and save all of the changed files, just some of them. (I might have files with some debug changes, for example, that I don't want to save.) But it would be great if this dialog also showed a list of all VIs that need to be saved, so I know if it's only 2 more that will get a prompt, or if it's 35. Two more are okay to do a manual check out for, 35 not. Then I probably will check out a whole class or folder of classes. So please take away the guesswork of how much there is to save!
So, due to massive lag in the project environment, borked graphics drivers on the virtual machine and the resulting random rearrengement of objects on the front panels, i've Locked all objects.
Now, trying to delete a control from the block diagram nothing happens, which is technically correct. No information or warning, however, is borderline Bug in my book. I'd expect a popup "Object is locked", not just a silent denial.
LV2014SP1f3 (which for some reason is 18.104.22.168 instead of 14.1.3.x, but that is another discussion)
in "debug mode" (retain wire values), be able to choose the "radix"
something like this:
yes, I know the custom probes, but I'm not talking about that. .
It would be nice and useful to have this in the native behavior of LabVIEW
sorry for my poor english, i do my best
It would be quite helpful if LabVIEW would automatically grow down a function when bringing a new wire to build array/string concatenate/build cluster/interleave arrays/build matrix/compound arithmetic, allowing the programmer to make a new connection to the function if the function currently does not have room for the connection.
Even better is if it would grow/insert where the wire is near the function, below an existing connection, similar to 'ADD INPUT'.
The In Range and Coerce function is frequently used to determine whether a value is within range of an upper limit and lower limit values.
But when it is out of range, you often also want to know whether the value is out of range too high, or out of range too low. It is easy enough to add a comparison function alongside and compare the original value to the upper limit. It's another primitive and 2 more wire branches. But since comparison is one of the primary purposes of the In Range and Coerce function, why shouldn't it be built into it?
The use case that made me think of this that as come up in my code a few times over the years is with any kind of thermostat type of control, particularly one that would have hysteresis built into it. If a temperature is within range (True), then you would often do nothing. If it is lower than the lower limit, you'd want to turn on a heater. If it is higher than the upper limit, than you'd turn off the heater. (Or the opposite if you are dealing with a chiller.)
Request: Add an additional output to In Range and Coerce that tells whether the out of range condition is higher than the upper limit, or lower than the lower limit.
(That does leave the question as to what should the value of this extra output be when the input value is within range. Perhaps, the output should not be a boolean, but a numeric value of 1, 0, and -1, perhaps an enum.)