strict self-reference for a reentrant vi

[Intaris]

OK, I have the following scenario.

I have a background process which takes a reference of a buffer VI and auto-updates the data.  To do this I need to pass it a strct VI reference so that it can call the VIs associated with the references.

Up until now we've maintained several buffer VIs for several instances but I wanted to make a single re-entrant VI work and thus eliminate this overhead but I ran into a small problem.

I need to get a strict reference to my reentrant clone.  I can't go via "Open VI Reference" because this allocates a new clone and I can't cast a simple VI reference to the required strict type via "cast to more specific class".

How do I go about this?

I'm using LV 2011 SP1.

Shane.

[Norbert_B]

Shane,

there are two feasable methods to address this:

a) Use a FGV/AE to create, manage and cleanup the buffer VI instances. Methods of this FGV/AE supplies access to either the handle to the buffer VI or provide access to read/write functions of the buffer VI.

b) Quite the same approach: Use LVOOP with aggregation pattern to manage the buffer VIs. Advantage of b) in comparison to a) is that you can use different types of buffer VIs with the same API (dynamic dispatch).

Other methods might include queues and stuff, but i would not expect that to be feasable...

hope this helps,

Norbert

[Intaris]

OK these are solutions to what I want to do but is there no way to do it the WAY I wanted to do it?

Is there no way to get a strict reference to a reentrant VI from WITHIN the VI?

I'm currenbtly simply opening a reference to the reentrant VI (strictly typed) and passing this as a value to my buffer routines so I can control which buffer is being used where.  Not the most elegant solution but it seems to work fine.

Shane.

Ps If I would go the LVOOP route, my "buffer VIs" would disappear completely and the functionality would be replaced by object instantiation.  This is easy but the approach is currently not favoured for other reasons.

[Norbert_B]

---

@Intaris wrote:

[..] 

Is there no way to get a strict reference to a reentrant VI from WITHIN the VI?

[..]

---

Which VI do you refer to in this sentence? The instance of the reentrant VI or the caller?

Norbert

[Intaris]

The instance of the reentrant VI itself.  A strictly-Typed "Self" reference.

[Norbert_B]

Hm... interesting question and i found no solution.

But there are plenty of other ways to solve this, so workarounds are available 😉

What advantage do you see by having access to a typified "self" reference?

Norbert

[tst]

---

@Intaris wrote:

I can't go via "Open VI Reference" because this allocates a new clone and I can't cast a simple VI reference to the required strict type via "cast to more specific class".

---

Two options:

1. Use the clone name property of the VI to open a reference to the specific clone. AQ said a few times recently that this was a use case which was never thought of in LV R&D and it has some potential issues.
2. Use Type Cast to convert the reference to a strict one. I think it should work, since the wire still has the same data, but I haven't tried it specifically. I would probably prefer passing the reference explicitly.

[Intaris]

Type cast doesn't work.  I cannot wire a strict reference to the middle terminal of the type cast function.  unusually enough, flattening to string and back to strict type doesn't give a broken wire, but also doesn't work.

Using the clone name to open a reference doesn't work either.  At least it dodn't for me.  I was hoping that would work, but apparently not.

I have used a workaround where i open a reentrant strict typed reference (Open VI reference) and then pass this reference to the various places I want to access the buffer.  Seems not ideal, but it works fine.

Regarding use case:  I'm making changes to existing code and ti utilises a backgground process which registers strict vi references to call them whenever new data is ready.  It's not how I would ideally implement the code myself but as I said, it's making modifications to existing code so I can't just throw the rest overboard.....

Shane.