LabVIEW
All VIs in Memory (Including Clones)
@joshua.l.guthrie2.civ wrote:
@Kyle97330 wrote:
Can you explain why you are trying to do this?
It may be that there's an alternate way to do what you want, but by focusing only on the "App.AllVIs" property and not your general task, we can't suggest anything else.
Partially to see if it can be done. Partially, to get better visibility on what's going on. My application is making LOTs of clones. I could see a situation where I'm making many more than I need to.. let's call it a clone leak.. and having an additional troubleshooting tool would be nice.
So, since this is for a specific application and not for a general reusable debugger, what's stopping you from finding all of your reentrant VIs (or at least all the ones you're worried about becoming a "clone leak" problem) and changing them slightly, like so:
@paul_a_cardinale wrote:
If you want to get cuhrazy, try this.
It seems that assumes that 50 clones are numbered 0..49.
Sadly, that's no guarantee. If you go wild with clones, there numbers could be anything. There's 0 guarantee that their numbers are sequential or start at 0.
If you know there are n clones, you'd have to start at 0 and loop until you get all 50. And hope the number of clones didn't change while looping.
If the goal is to make a "stop all", you can loop over the clones until the original VI becomes editable, or something similar.
Search LabVIEW like a graph!
@drjdpowell wrote:
You might want to look at the code in this tool: https://www.vipm.io/package/lava_lib_labview_task_manager/
It was developed over this old conversation: https://lavag.org/topic/14921-labview-task-manager/
That used to be very, very slow, as each clone name was recalculated in it's entirety. By removing the bulk of the clone name calculation before the loop, it was 1000X faster.
That was years ago though. Maybe someone fixed that. I probably should have mentioned it to someone back then, but my only goal was to steal the clone name algorithm asap.
What didn't came up yet is that IIRC there's a difference between SubVI clones* and dynamically opened clones.
IIRC, SubVI clone* names are totally different, esp. if they are DD class methods.
I'm not sure what the result of NumberOfClones reflects...
* instances automatically created because the reentrant VI is used in another VI.
@Kyle97330 wrote:
@joshua.l.guthrie2.civ wrote:
@Kyle97330 wrote:
Can you explain why you are trying to do this?
It may be that there's an alternate way to do what you want, but by focusing only on the "App.AllVIs" property and not your general task, we can't suggest anything else.
Partially to see if it can be done. Partially, to get better visibility on what's going on. My application is making LOTs of clones. I could see a situation where I'm making many more than I need to.. let's call it a clone leak.. and having an additional troubleshooting tool would be nice.
So, since this is for a specific application and not for a general reusable debugger, what's stopping you from finding all of your reentrant VIs (or at least all the ones you're worried about becoming a "clone leak" problem) and changing them slightly, like so:
If it was a hard requirement for me, this is probably the approach I'd take. I'd make a class that managed what was opened. I'm just kinda shocked that NI don't have a built-in methd that does this w/o doing crazy stuff.
I dug around in my "experimental" folder. 😇😈
I think the attached VI (LV20) does a pretty good job and is pretty clean.
I didn't test the behavior for reentrant DD VIs though. Pretty sure their name code is different.
Keep in mind that Generate Clone Number.vi does some math and simply adds the clone number. If you want performance, copy Generate Clone Number.vi and make it accept an array or make it return the "clone 0" reference name and add the actual clone number. Shouldn't be too hard.
