Detecting queues and notifiers in a cluster

[magicbean]

I have a cluster of several queues and notifiers which is used in many places in the code. They are not grouped according to queue/notifier type but according to function so I don't really want to reorder them or turn them into an array of queues and an array of notifiers.

When it comes to releasing the resources I was trying to find a way to iterate through the cluster and release each resource according to its type. So far I can't find a way and I am releasing the resources like this:

The best I came up with was a naming convention where the names of notifiers ended with N and queues with Q but although I can iterate through the names, and make a decision based on the spelling, I can't work out how to then access the queue or notifier to release it.

(It looks on here as though the wire from 'String Subset' isn't connected to 'Reverse String' but that's just a glitch in pasting the image).

I tried looking at the class names of all the controls in the cluster but both the queues and the notifiers are both 44 (TypedRefNum).

I can manage with what I have, but thought it would be neat to have some code that iterated through and release everything automatically (without rewriting all the code).

Any clues?

[Kevin_Price]

AFAIK no, you probably can't do much to improve on the big "ladder" of parallel release operations because all your queue and notifier refs are statically typed.  All you *might* be able to do is form arrays of refs that are of the same datatype so you can autoindex over that *subset* of refs.  But just from the wire colors, it's clear that you have at *least* 2 notifier types and 2 queue types, so probably a Pyrrhic victory at best.  

-Kevin P

[Kyle97330]

Agreed that probably the only way you could do this is if they were the same data type, so you'd have to make them all a "universal" data type, i.e. all being a Variant data type or all being references to the same class that contains all of those data types in them somehow.

The main thing I would note is that if it makes you feel better, you could put all of those "release" functions in-line with each other on a shared error chain instead of using the "merge errors" node.  Both "Release" functions are set up so that they run even when an error in is found, so if one of your references was bad and made an error come out the rest would still release properly if they came after it in order.

[mcduff]

You may be able to accomplish what you want using Variant parsing; but it would be a lot of work. If you only have a limited number of cases to parse, that is, the payload your queues and user events are not overly complicated, then it may be feasible for a limited number of cases.

[BertMcMahan]

Unfortunately this is one of the downfalls of a strictly typed/non-fully-OOP language. LabVIEW sees all of those refnums as different types, not just different values of the same type. In other words, a queue of strings is a fully different type than a queue of I32's. "Release queue" does happen to work on all of them, so it's sort of acting like an Object, but you can't actually get at it or do anything with it externally, and you can't cast those queue or notifier references to anything.

You COULD make your own OOP wrappers for all of your queues and refnums, and store an object that has a "Destroy queue" or "Release queue" etc, but you'll need one for each type of queue you use. Like Kevin said, you probably won't save much work.

(See this thread for some further reading: https://forums.ni.com/t5/LabVIEW/how-do-i-create-a-VI-that-accepts-all-queue-references/td-p/1696836)

[magicbean]

OK - it looks like there is no better solution than my current one.

Thanks, all!

[BertMcMahan]

Perhaps a slightly improved solution could be to write a script that creates a VI that'll close all queues, notifiers, etc. in a given cluster. You'd just run it every time you update your main cluster. Probably not worth the time, but maybe you update that cluster a whole lot.

[paul_a_cardinale]

Post the typedef of your cluster.  Maybe I can come up with something.

[Yamaeda]

I guess the easiest would be to wrap the queues/notifiers in classes and have a Close/Destroy method.