How can a DVR created in a functional global called by the main vi and a dynamic vi retain it's data?

[nathand]

I should clarify one point here. It's fine if the FGV creates the DVRs, so long as when it does so it's called from the Actor and not from the dynamically-launched VI. You don't have to create the DVRs in the Actor itself, you just need to create them within the actor's call chain in order for them to follow the actor's lifetime.

[Thomas_robertson]

Zombie Thread arise!

I wonder if LabVIEW specific design patterns have been created to deal with this?  

I was pondering a pain point we have today in our code:

We call a plugin vi dynamically and close it afterwards.  That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1.  In order to not loose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy, where it eventually gets copied again into another DVR 3 where it is put into our application wide data store.  At different times in the program the global data store gets read and DVR 3 accessed.  We have to be careful to not delete DVR 3 since it's widely used.  Sometimes we need to copy the data and create new temporary copies for use in local places and then clean up that local copy.

We've been thinking we want to get away from clusters with DVR's in them and move to classes which represent data.  But how DVR's live in those classes and specifically when those DVR's will just disappear on us is frighting.  It could lead to us making methods that copy a class for the sole purpose of creating a DVR from a new layer of the call hierarchy. 

Anyway, I feel like surely someone has thought about all this and probably written a paper showing design patterns on how to make LabVIEW program's that use DVR's without loosing data or leaking memory and while encapsulating all the details.  Is that too much to hope for?

[JÞB]

Has anyone ever tried to  configure the FGV call setup to " Load and retain"  and is the FGV using an USR or a globally initialized FBN?.

Subtle differences. 

[drjdpowell]

---

@Thomas_robertson wrote:

We call a plugin vi dynamically and close it afterwards.  That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1.  In order to not lose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy...

---

Why are you using DVRs instead of by-value data for these short-lived processes that only need to return data?

If you do need DVRs, create them in the Caller and pass them into the plugin.

[paul.r]

---

@drjdpowell wrote:

---

@Thomas_robertson wrote:

We call a plugin vi dynamically and close it afterwards.  That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1.  In order to not lose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy...

---

Why are you using DVRs instead of by-value data for these short-lived processes that only need to return data?

If you do need DVRs, create them in the Caller and pass them into the plugin.

---

Agree that this case sounds like by value could work.

If you actually need DVRs, another option is to create a an API that includes a daemon that creates the DVR, and returns it to the caller - then the daemon just sits and waits until it is explicitly closed through the API. 

[Thomas_robertson]

connector panes for plugin's where fixed years ago, so, it is what it is.  

However, within our program we have freedom, that's why I'm intrested in design patterns for objects that use shared DVR's.