Comrade

Name: Falk Schneider Submitter: Comrade Submitted: 18 Jun 2015 Category: *Uncertified* LabVIEW Version: Not ApplicableLicense Type: BSD (Most common) This snippet demonstrates how to handle the runtime contextmenu of various controls in one single dynamic event case. Notice how you only need to bundle the different references of all the controls into one "Register for Event" input. Discrimination between the different controls happens inside the dynamic event handling case as is shown here with singling out one control for which the conxext menu remains standard while for all other controls just a singular menu item is generated. This was created as an answer to the following post: https://lavag.org/topic/4796-control-user-run-time-menu-checkmark/#entry26461 LabVIEW version is 2013 Click here to download this file

Name: FPRefs2VariantAttributes Submitter: Comrade Submitted: 02 Jun 2015 Category: *Uncertified* LabVIEW Version: Not Applicable License Type: BSD (Most common) The VI acquires all front panel control (and indicator) references and one by one passes them into a variant using its attributes. This way of storing the references makes them faster to be found within an application than by storing them in a cluster along with their name and using "search 1D array". The idea of this use case came from a nugget by NI's Darren. Click here to download this file

Now this is quite old and maybe it didn't work back then, but with LV 2013 there is no problem doing this... https://lavag.org/files/file/265-falk-schneider/

Thanks Hooovahh and rolfk for your answers. Summarized in terms of my questions: Concerning Question 1: I don't need to close the references, but I may - closing static refnums is in fact a NoOp function Concerning Question 2: It will always work, because the acquired refnums point to child elements of the FP and are therefore static refnums. See answer to Question 1. Correct?

Sorry for bringing this up again. My questions regarding closing references is towards references that are generated (opened) in the init state of an application and then transferred in to some kind of data type where they are being kept available to use at one's heart's desire. A regular use of this scheme is to get all FP element references of the UI at startup and passing them into a variant using its attributes. This way one can call on the attribute of that variant wherever wanted to retrieve the desired control reference. A function that does that can be seen here. Question 1: Within the functionlinke above, do I close the control references or will that make them invalid afterwards and therefore render the variant attributes useless? In other words - is the value on the wire of the reference a reference to THE actual control reference or is it THE reference itself? Question 2: According to the rule not to close any parent references before all actions on their child references are completed, the attached function should never leave me with usable control references. Yet it does. All the time. Without ever failing me. How come?