Source code of the Abort running VIs dialog?

[1984]

Hi,

is the Abort Running VIs dialog open sourced? Or is there any VIs can kill reentrant instances stuck running in the background?

Thx a lot!

Oh, yes! You are 100% right and thanks for letting me know that I should never be in a state in which I have reentrant VIs stuck running in the background. ... wait, what? Sure, mate! You are right again... this is bad practice and I shouldn't do it EVER.

Well nonetheless it seems a VI like that.

[rolfk]

Not the source code of that function (it could or could not be an actual VI, since it is LabVIEW internal it could just as well be implemented in the C++ code in LabVIEW). But a simple Google search will point out a number of possible solutions, the first of them was for me this: https://forums.ni.com/t5/LabVIEW/Abort-All-Running-VIs/td-p/702484/page/2

[Bob_Schor]

There is an Application Property called "All VIs in Memory" that returns an array of Strings that list all VIs in memory.  You can feed that to a For Loop, use Open VI Ref to get a reference to the VI, check its Exec.State to see if it is running, and close it if it is.  The first time I tried this, I'd written it as a VI (of course!), it found itself, and promptly closed itself.  I'll let you figure out the (almost trivial) way to fix this embarrassing problem ...

Bob Schor

[1984]

Yes, I did a simple google search and found this VI. The VI uses the App.ExportedVIs property which doesnt list the reentrant instances, so it can't stop them. It stops everything else, which could be useful in some cases (eg: modals), but not for reentrants.

[Bob_Schor]

---

@1984 wrote:

Yes, I did a simple google search and found this VI. Which VI?  Can you attach it?  The VI uses the App.ExportedVIs property which doesnt list the reentrant instances, so it can't stop them. It stops everything else, which could be useful in some cases (eg: modals), but not for reentrants.  What happens if you try "All VIs in Memory", as I hope I suggested?

---

Bob Schor

[1984]

Looks having the same problem as what Rolf linked. Not matter if I run the VI (after - of course - I have fixed that embarrassing problem), my lib is still locked and the only thing I can do is closing the project which throws the Abort All Running VIs which shows that clones are indeed running.

[1984]

---

@Bob_Schor wrote:

---

@1984 wrote:

Yes, I did a simple google search and found this VI. Which VI?  Can you attach it?  The VI uses the App.ExportedVIs property which doesnt list the reentrant instances, so it can't stop them. It stops everything else, which could be useful in some cases (eg: modals), but not for reentrants.  What happens if you try "All VIs in Memory", as I hope I suggested?

---

Bob Schor

---

I was still writing my replying to Rolf's comment when yours arrived. I'll make sure I will use the quotes in my future comments to avoid such confusions. By "this VI" in my previous comment I was referring to the linke sent by Rolf.

Yes, I got your suggestion and implemented it (see above) with no success. Could be something stupid I've done, but no luck killing the reentrant instances by using the All VIs in memory either. My lib is locked and the running instances still show up in the Abort running VIs dialog.

[JÞB]

---

@1984 wrote:

Looks having the same problem as what Rolf linked. Not matter if I run the VI (after - of course - I have fixed that embarrassing problem), my lib is still locked and the only thing I can do is closing the project which throws the Abort All Running VIs which shows that clones are indeed running.

---

I believe you have not opened the vi ref with the Reentrant flag set.  You need to get a ref to the clone instance. So. you would need to try open VI ref Flag0x08 ,  if not err 1096 (vi is reeneterant) get clone names VI Clone Name Property 

[1984]

---

---

I believe you have not opened the vi ref with the Reentrant flag set.  You need to get a ref to the clone instance. So. you would need to try open VI ref Flag0x08 ,  if not err 1096 (vi is reeneterant) get clone names VI Clone Name Property 

---

I'm not there, but for sure close. I open my reentrant VIs like in the screenshot below (1). I'm unsure why should use 0x08 I if the VI is set to "preallocated clone reentrant" in the VI properties, but thats most likely a gap in my knowledge. 

(1)

If I run the VI with 0x08 like below (2) then I can kill them with the VIs linked earlier, but I dont know how to feed them with inputs (the numeric and variant on (1)).

(2)

So I guess we are almost there. Now the question is how to set the inputs of the clones if I start them as show on (2)

[JÞB]

The fire n forget ACBR does leave you with a ref to the clone AS IT LAUNCHED! but doesn't trace status of the clones very well

 I try to avoid having unmanageable clones.  One helpful code chunk that I do use it this running inside the plugin::

I actually use the Queue as a named map.  a Global Map of "VI Names" to Void Variant with Attributes "CloneName" type VI Refnum would be faster but Maps didn't exist when I did that the first time

The trick is to eliminate the element by vi ref from the named queue before closing the clone.  but it does maintain a context wide accessible list of active clone instances per reentrant vi.  Very useful when you don't know how many plugins will launch!  A quick Get Queue Status will always return a list of running <Clone Name, VI Ref to Clone Instance>[ ]

Attached saved in 2019