Better context help to identify FP objects.

[altenbach]

Looking at code of others, it is sometimes difficult to tell what kind of control or indicator we have, especially since some can be made to look quite similar, even though their function is quite different.

Example: If there is a graph and the label has been changed, it is not easy to find out if it is a waveform chart, a waveform graph, or an xy graph.

To figure it out, we have a couple of options, and none are very intuitive:

• Look at the datatype (not reliable, because there is overlap) 
• Look in the right-click menu for specific items (e.g. if there is a chart history entry, it's probably a chart). 😉
• Show the terminal as icon and look at the icon, then try to remember how each looks like by comparing with the palette.
• ...

Suggestion:

Maybe always, but at least whenever there is no custom description (i.e. cases where the context help shows "no description available"), it should also give the generic name of the object, the way it was called in the palette.

For example if I drop a string from the system palette, the label is simply "string" but the context help should show "system string" in the second line: the tag it had in the palette.

Of course customized controls should indicate that fact too somehow.

Similar labeling should also apply to cluster elements.

[Intaris]

I agree wholeheartily but I would go a step further.

Having made a foray into C# last year, I came to appreciate the properties pane which can be left open in the editor.  This displays a whole lot of information about the control currently highlighted and allows setting the parameters from the pane directly without having to go to an extra dialog.

Wouldn't it be great to be able to change properties (like chart length) from a docked palette instead of having to right-click and go to "properties"?

[tst]

---

Wouldn't it be great to be able to change properties (like chart length) from a docked palette instead of having to right-click and go to "properties"?

---

If memory serves, I seem to remember someone saying that NI already tried that in the past, and that was what resulted in the property dialogs. I agree that it's generally a lot more convenient and you can actually get this in LabVIEW, but only if you're working on an ActiveX control (or maybe a .NET one as well?).