As mentioned here, Chrome is now the dominant web browser worldwide, but acessing remote front panels using Chrome is still not officially supported by NI (more details and links are in the quoted thread).
While there are some hints that several users had success back in 2010, I was not successful so far.
IDEA: There needs to be official NI support for the dominant browser and NI should invest some effort to get this working seamlessly.
I don't like the way that long file paths are shown in path controls and indicators: If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit. This can be pretty confusing.
One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown. I've seen this in other UIs and it should be a natural thing for users to understand.
Here's an illustration:
I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.
When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:
Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons. Which one is which? There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon. Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.
NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW
The current commenting practice in the BD is to place free floating comment number labels and write the comment in a text field as in the example below.
- comment number labels do to stick to the code block. if the code number block is moved the comment has to be moved as well.
- no link between number and comment text block
This unsophisticated way of commenting LabView code lead to the lack of comments in general. Usually a new programmer can understand what happens, but not why a function is implemented like this.
LabView provides the Advanced Code Commenting Functions.
The comment block is more then just a text block. Basically it has a comment ID, the comment itself and a comment category.
By the context menu the following functions are provide:
Adding a comment in the comment block incorporates two steps (after selecting Add Comment from the context menu):
1. Sticking the automatically generated comment ID to a particular code block just by selecting the item the comment belongs to.
This could be any type of code: wires, SubVIs, the whole Case, a particular Case, Sequences....
2. Writing the comment
If the mouse pointer is set over a comment ID the comment is shown like a tool tip and disappears as soon as the mouse is moved away.
I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.
(structure) rick-click » visible items » Structure label
Large string constants, like to one shown below, can really get in the way. I would like to double-click the border and have it collapse, like the LV 2010 Cluster now does. Putting large string constants in a VI, or rolling them up, are some work-arounds, but this would be easier...
Double-Click the "text" icon to reverse.
My idea is simple: Put the connector pane on the front panel next to the VI icon.
Why: Right clicking to show the conpane means extra clicks that would not be necessary if it was always there. It would also be solve the problem of saving the VI with the connector pane hiding the VI icon.
It'd be usefull for develloper and especially application user to improve graph control by adding to Graph direct access to Plot Visible property on plot legend.
For the time being, you have to go to color and choose transparent or to change visible property dynamically.
I propose control like that ... but we could find another idea to access Visible property.
I don't know how many times I've added a case statement post-programming, but I do know that there isn't an easy way to make a tunnel the case selector. Usually I delete the tunnel and then drag the case selector down and then rewire, there should be an easier way. For loops and while loops have an easy way to index/unindex or replace with shift register, why can't a case statement be the same?
It could be nice to have a context help on coercion dots to see what is the expected type of the data that is supposed to be wired to. This way you can rapidly determine what kind of conversion to use to avoid the coercion dots.
When creating a subVI from a selection, LabVIEW should do two things:
It should also try to make the FP of the subVI cleaner, but that's another matter.
Hello, this is my first post in this forum and I don't found ideas about this topic. I hope you like it.
Well, time ago I started to work with LabVIEW, It's powerful, but there are some kind of issues that I want to explain here. Now I'm get involved in a big project for a very big aerospace company, and I'm developing a complex application to acquire some data and process it. Well, this software is in development by some people and I have an idea for the work flow.
I explain it with an example:
If we have in every VI a little data base with some notes ordered by type or something we can read the code or we can start to work in a VI faster. Imagine that you have an event structure with several cases, and you put some notes like you can see in the following image:
Now, I'm able to revise quickly the code reading all the notes and start working only in the "TO DO" zone. But let's do a more complex design: Now I open my project explorer, and open the "Note manager" that could be like this.
Here it is the real advantage of this tool: All the design are done and now I want to improve the application. Lets go only to the notes that interest to me: "TO DO" notes. If I double click on an element LabVIEW opens for me the VI centered in the zone that is interesting for me. And some more: I can check the work I've done and I can add new notes only with a click.
The more complex the project is, the more useful is this system. So, what do you think?
It would be nice if NI added "Mouse Scroll" (and its counterpart filter event) to the supported events. Today, you can do this by using the mouse input VIs in a separate loop and polling, but that's not a very nice solution.
I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.
The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.
As it is already wired, inline and not broken, dropping a For Loop around it should not break my code!
Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array.
Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.
This would remove one step required for most use cases, speeding up my development experience.
It should be nice to limit the action of Ctrl-B to a selected part of the block diagram.
For the moment the Ctrl-B removes all brocken wires in the complete VI.
Sometime when you have a case structure with multiple cases ... and when you have multiple brocken wires in many cases ...It is usefull to keep non visible broken wires...
The broken arrow (list of pending errors) will then help you to find all locations to modify.
After 2011 we have the option to ignore all the missing vi's which are missing. But after loading the project if a vi is loaded and if it has a missing vi then there is no way to check from where it has to be loaded (Expected path of the missing vi). So it would be a good option to check the Expected path of the missing vi after loading its caller (May be in the properties of the missing vi).