LabVIEW Idea Exchange

The Close Reference –VI could be integrated into the Property Node ore the invoke node.

I would recommend that the reference output could be activated or deactivated.

A deactivated reference output

• would change its appearance
• would close the reference immediately after a the call.

An activated reference

• should require a connected wire on its output. Otherwise an error should be indicated (somehow).

My comments  

• An integrated Close Reference –Function would simplify the code and improve the readability.

   

• The output should be changeable in the context menu / pop-up menu of the Property Node.

   

• The default state needs to be discussed. I would recommend to close it by default. Sometimes it is not necessary to close the reference – it would lead to a void operation --> so what? Sometimes it is required to close it later. I think in this case you would find it out after the first run of your vi.
• Usually it would not mater if somebody would let some references open. LabVIEW closes open references finally. But if an application should run for several days, left open references could lead to problems. Because of this I think that it is better to close to often than left some references open.
• I am not sure how LabVIEW should react if an activated reference output would not be connected. I would recommend to indicate an error. In my opinion this would be an additional new feature to LabVIEW. LabVIEW does check inputs only. But this is another problem to discus.
• Perhaps there are other places / VIs to implement an auto-close reference output.

The Combo Box is a useful means of linking "machine readable" strings and human readable text.  Unfortunately the current item editor lacks a key feature.

You cannot enter special characters (escape codes) or nonprinable characters \FF since any "\" entered is replaced by the "\\" escape  This means that if I want to add any non printable char to a value I need to write a vi to edit the strings and values property interactively and then type-def the control.   to edit the typedef I again need to disconnect from type def edit the strings and values from a vi, create a new custom control (no type def) and replace the original control in the type def with new control and apply changes.  Kinda a pain!  Again the values property will accept any string so this is only an items editor feature and does not change the combo box object in any manner

Many embedded applications use non printable characters in the commands. Most commands translate well into human readable text.  the combo box's auto completion feature allows an intellisense like feel to the UI but the difficuly mapping HRT to strings with non-printable characters seriouly increases the development and maintainence of these controls