Unlocked Event X Control

[GregFreeman]

I have a user event that is created in the Exec State Change event in my X Control, if the reference is null. This same user event is destroyed at application shutdown. Otherwise, it should last forever so the X Control works in edit mode as well. This works fine.

 

The one case I can't figure out how to handle is if I unlock my X Control. If I unlock it then apply any changes, the user event refnum goes null. I know this because I added a one button dialog to be displayed when the user event gets created. The fact that it's being created tells me the original refnum no longer exists. But, I never closed the existing user event refnum, so I'm worried I have a memory leak.

 

Is there any good way to capture the X Control going into edit mode so I can destroy the user event refnum in that case as well?

Edited January 9, 2015 by GregFreeman

[drjdpowell]

Your Xcontrols instances go idle when you unlock the XControl, thus destroying all their owned references just like any other VI going idle.  So I wouldn’t worry about a leak.

[Rolf Kalbermatter]

I have a user event that is created in the Exec State Change event in my X Control, if the reference is null. This same user event is destroyed at application shutdown. Otherwise, it should last forever so the X Control works in edit mode as well. This works fine.

 

The one case I can't figure out how to handle is if I unlock my X Control. If I unlock it then apply any changes, the user event refnum goes null. I know this because I added a one button dialog to be displayed when the user event gets created. The fact that it's being created tells me the original refnum no longer exists. But, I never closed the existing user event refnum, so I'm worried I have a memory leak.

 

Is there any good way to capture the X Control going into edit mode so I can destroy the user event refnum in that case as well?

 

Are you sure it gets NULL, or are you rather using the "Is Not a Path/Refnum/Number" to determine if it is valid?

 

If it is the first case I would be stumped since the (internal numeric magic cookie) value shouldn't just change like that, but if you use the NaPRN function then that is indeed expected behaviour like dridpowell explains. In LabVIEW the lifetime of refnums is automatically terminated at the moment the top level VI in whose hierarchy the refnum was created goes idle. And while the numeric value of the refnum remains the same it is not a valid refnum anymore after that (and never should be able to get considered valid again in any feasable lifetime of the LabVIEW application instance).

[GregFreeman]

Your Xcontrols instances go idle when you unlock the XControl, thus destroying all their owned references just like any other VI going idle.  So I wouldn’t worry about a leak.

All I needed to know. Thanks!