LabVIEW Idea Exchange

Bug replication steps:

• Ensure that the "Connector pane terminals default to Required" option is ticked (found in Tools >> Options >> Front Panel).
• Connect an indicator to a VI's connector pane.
• Right-click the indicator and select "Change to Control".
• The indicator changes to a control, but the connector pane terminal is Recommended. It should be Required (should obey the environment setting).

Notes

• Mis-connecting an indicator to the connector pane while believing it is a control can occur moderately frequently, especially when working with front panel elements that do not look very different when they are controls vs. indicators, for example: variants, objects, typedef clusters, system-style strings or paths.

The name of the "Get Date/Time in Seconds” function is misleading. The function should be renamed.

Details

• The current name does not make it clear which Date/Time it is going to return. The words "now" or "current" are missing.
• The "In Seconds" portion is misleading and unnecessary. The function correctly returns a timestamp data type. The timestamp represents a moment in time that is expressed not just in seconds, but also using lots of other time units such as days, hours, minutes, ms, us, ns, etc. I understand that when a timestamp is converted to a DBL, the value represents the fractional number of seconds since the beginning of the epoch, but this is an implementation detail. It should not be part of the name of the function.
• “Get Date/Time in Seconds” would be a suitable name for a conversion function that takes in a formatted Date/Time string and outputs a DBL that represents the number of seconds since the beginning of the epoch.

Names of equivalent functions in other languages

• .NET: System.DateTime.Now
• C++: std::chrono::system_clock::now()
• Python: datetime.now()

Notice that the equivalent function names contain the word "now" and omit "in seconds".

Perhaps the best new name for the function would be “Get Date/Time Now”. This name would be very much in line with the .NET, C++ and Python equivalent function names. This name would earn the "let's not reinvent the wheel" prize.

Nevertheless, I would be happy with the following names too:

• “Get Timestamp Now”
• “Get Current Date/Time”
• “Get Current Timestamp”

Notes

• Changing a primitive name may break VIs that use VI scripting to find or create this node. This is a downside. I believe that in this case the long-term benefits would outweigh the relatively minor annoyance of hopefully relatively few developers having to modify those scripting VIs to use the new primitive name.

Idea:

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

Reasons:

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

To achieve this, I found 2 techniques:

1. Replace by a temporary Control file:

  - Create a new VI of type "Control VI";

  - Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

  - Save the .ctl file to a temporary path;

  - Use method GObject.Replace with parameter "Path" on the old control / constant .

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

2. Recode the Replace method from scratch:

  - Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

  - Copy all relevant properties from the old control / constant to the new one;

  - Reconnected its terminal to the wire on the block diagram if needed;

  - For a control, relink locals, linked properties nodes, linked method nodes, references;

  - For a control, reassign it to the connector pane if needed...

  - ...

  - Delete the old control / constant.

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

Regards,

Raphaël.

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

Thanks!

Currently if you draw a diagram disable structure around a section of code any wire coming out of it will be set to "Use Default if Unwired". This is almost never the desired behavior, and can easily lead to bugs if people forget to connect wires through on the Enabled case. The VI should be broken until the developer makes any necessary changes in the Enabled case.