All the other string/number conversion primitives are polymorphic (i.e. can accept arrays as well as scalars), except for the "Format Value" and "Scan Value" ones. Can we make those polymorphic, too? I hate that I have to do things like this:
A merge of those 2 ideas :
Sometimes I know I want an initiaized shift register, but I am not sure about the data type, because it might change during program development. Sometimes I have a cluster holding a few variables, but later I need to add a few more elements.
If I initialize the shift register with a diagram constant, things break whenever I change the cluster inside the loop and I need to redo the diagram constant by "delete the constant, right-click the SR, create constant".
I would prefer a mode where the initialization is generic and simply adapts to whatever type is wired from the inside. This simply ensures that no data is retained between calls, just between iterations of the loop as often needed.
In summary, we should have an option to generically initialize a SR (or feedback node) and it would look different to indicate that fact. For example it could have a small cap as in the attached image.
(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)
It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.
Consider a distributed program, where client PCs have GUIs that show the values of variables hosted on the server PC. Suppose the server has to change its IP address.
Bind the indicator to a Network Item (hard-wiring the address of the server)
You'll need to update the server address in every single indicator
Write extra code to read the server’s address from a config file, and programmatically do the data binding
It’s extra code
Bind the indicator to a Project Item, and assume that the “My Computer” target refers to the server. Update the server address by updating the .aliases file
The client PC can’t have an alias of its own
Have separate targets for the Server application and the Client application (each target can have an alias). Bind Client indicators to project variables hosted on the Server (no extra code required). Update the server address by updating the .aliases file (don't need to update each individual indicator).
Make the probe display remember the scroll position. This in order to avoid the scroll to go back at top when looking at another probe and coming back.
1-scroll all the way down.
2- look at another probe.
3- go back at first probe and have to scroll down again.
Normally we need "Equal?" function combined with a constant.
With this idea the code is smaller ...
The LabVIEW project window has two tabs: (1) Items (2) Files. The "Files" view is very useful to me as a quick check to make sure all subVIs are loaded from expected locations.
I am not aware of an equivalent view into the current Vi hierarchy if we don't use a LabVIEW Project. Maybe I haven't found it yet.
My Idea is to have an optional window that show the current VI hierarchy in a layout very similar to the "Files" view of the LabVIEW project, even if we currently don't use a project.
(Image for illustration stolen from this article)
I really like the notion that you can put a Cluster defined by a TypeDef on the Block Diagram (where it "looks like a cluster", and is possibly quite large), right-click it, and have a Custom Icon that you (should have) created for it show up in its place. Very mnemonic.
How about extending this idea to all TypeDefs? I have been known to TypeDef certain arrays ("Buffer Type", "Message Queues"), and rather than have an Array Constant (with the Black Hat that clues the reader that this is really a TypeDef) on my Block Diagram, I can have a Custom Icon that might say "Message Queues" or "Buffer", thereby making it (again) mnemonic and clearer six months from now.
P.S. -- It wouldn't surprise me if this has already been suggested, but a search, possibly with the wrong key word, didn't find it.
LV's graph palette feels a bit outdated. Can we have the graph support an option for "google map" zooming and panning? That's what everyone who uses maps are used to... mouse wheel to zoom in and out on the graph, and click/drag to pan.
I realize some advanced zooming options wouldn't be supported by this mode (like just zooming x-axis or y-axis).
In the world of tab controls, a tab caption refers to the actual text in the tabs that you click on to select the different pages, see attachment "Tab Caption". Currently, there is no property node that allows you to change the font characteristics of the tab captions. The font characteristics can be customized non-programmatically by right clicking on the tab control and selecting Advanced/Customize. However, within the customize control all the tab caption properties are linked, so if I make the font color red for the page 1 tab caption, it will automatically change the page 2 tab caption text as well, see attachment "Customize". The same thing applies for the other font characteristics.
This functionality would be useful for those users who want more control over the aesthetics of their front panel. For example, if a user wanted each tab to represent a test that he was running he could change the individual text and color to represent whether or not the test passed, green "passed," or failed, red "failed."
If you try to "set variant attribute" and inadvertently wire in a blank string, this wipes out all other attributes from a list of attributes inside a variant. An error should be returned, but destroying the rest of the list of attributes should not occur.
When I have large projects with lots of classes, Labview's edit time environment slows down to a painful crawl. Almost every meaningful action triggers a recompile that gives me a busy cursor for 3-10 seconds. My productivity falls off a cliff and I avoid making important changes in favor of the cheap hack. (The dev environment has high viscosity.)
I often wish there were a way to turn off the compiler while I make a set of changes. I'm not interested in the errors at every single intermediate state of the code while I'm making the changes. I *know* the code will be broken after I delete some nodes or wires. Let me turn the compiler off, make my changes, and then turn it back on for error checking.
I'm sure there are lots of different solutions to address this problem. My preference would be to make compiling faster so it is unnoticable. I doubt NI will ship me a new computer with the next release. My second choice would be to stop loading all of the class' member vis when any single vi is loaded. I vaguely remember a discussion about that some time ago and it wasn't practical to do that. That leaves me my third choice--more control over what automatically compiles when I make edits.
It could be something as simple as Ctrl-Shift clicking the run arrow to toggle auto-compiling at the vi level. Or it could be a right click option in the project window that controls auto-compiling for an entire library or virtual folder. Either would be okay; both would be nice.
(For that matter, it would probably be a lot cheaper if NI just shipped me a new computer...)