XControl memory leak

[labviewman]

Has anyone experienced any problems with memory leaks in using XControls?  I'm having a heck of a time tracing down a leak that ONLY happens when the Xcontrols are part of my big program (no leaks when put into a simple VI that executes the exact same initialization and writes similar random (random to debug this problem) data.  I think it may have something to do with writing a True into 'State Changed' during the 'Data Change' event (I need to set that flag since I am keeping track in the Display State cluster the timestamp the 'Data Change' event occurred, which is read by the main.vi code).

I am relying SO much on this XControl to work correctly and I don't have time to write code to do what this control current can do.

Any help is appreciated.

Thanks,

Todd

[labviewman]

It definitely is related to writing ANYTHING into 'State Changed' during the 'Data Change' event.  Removing that from the state fixes it but I need to set that flag to write the value to 'Display State' since the main code reads the timestamp that is written in the 'Data Change Event', and w/o setting 'State Changed', the value written is not retained.

I am new to XControls (never had a need for them) so I'm hoping it is something stupid but when it works OK on a simple vi but not as part of a big program, I have to wonder... 

[Ben]

I have only heard of one case and that was traced down to a refernce being opened in the Facade. The fix was to only do the open when required and to cache the ref for subsequent use.

Otherwise post up your XControl along with a demo and someone may be able to spot the issue.

Ben

[labviewman]

I do create a Queue ref and a couple of Notifier Refs during the 'Display State Change' event but only if a) 'Run Mode'=True, b) One of the Notifier Refs is invalid (if one is invalid, all should be invalid, c) The 'Ctrl Name' of 'Display State' is Not Empty.  I verified using 'Beep' and indicator color changes this state is not being called all of the time.

The functions of the control are:

1) Keep a 1000-point history of it's values via a named-queue and Notifier (main code reads the notifier, queue is the 1000-point circular buffer). This history mush include values that don't change which is why I use Value(Signaling) if the data is the same as the last update.

2) Keep the current value of the indicator in a notifier (much faster for main program to read the current indicator values via a notifier than a property node)

3) Turn the indicator a color to indicate fault status (red=value passed is considered failed but user has not acknowledged the error, orange=value passed is considered failed but the user has acknowledged the error, yellow=there was a value passed that is in error but the user has not acknowledged the error, gray otherwise)

4) When a fault occurs, send the error details to a error-handeling queue (this is not yet put into the code)

When I was typing this, I realized a workaround to reading the 'Timestamp' of the latest update that is faster than using a property node as I intended, which is via another notifier just like 2) above (bypasses need to set 'State Changed' in The 'Data Change' event)...duh.  I'm sure this will work, but I'm puzzled why I had the memory leak in the first place and only with the main program and not this small one.

Thanks,

Todd