Jump to content

Unlocked Event X Control


Recommended Posts

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 by GregFreeman
Link to comment

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).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.