I didn't realize it until yesterday. But I need a similar behavior like Intaris is describing.
I want an easy way to rename a queue reference to something meaningful besides "queue out" because I'm bundling a few different queues together into a cluster and want to unbundle those queue references where I need them. I don't need the name to be defined at "run-time". I just want to name the queue reference while I'm developing during "compile time". I don't need to name the queue itself, I just want a meaningful name fo rthe queue reference.
I feel like there is a thread out there that describes an easy way to do this, but I haven't found it yet. Right now I'm just creating a queue reference constant out of the queue wire, naming that constant, then typecasting to the queue reference wire to that newly named constant. The problem is when I go and add something else to the datatype of the queue, I need to create a new constant of the queue reference, name that, and replace the old constant going into the typecast with the new one.
I know I should be using a typedef for my queue's datatype. But this is supposed to be a quick debug where I log data from a few different loops that shouldn't last beyond the week. But I don't think that creating a typedef of the queue datatype will even help me with trying to define a meaningful name for the queue reference that can easily survive a change in the datatype of the queue.
> That changing of the output label is essencial since it is the label name that shows up in the event case.
No it isn't. The label name that shows up in the event case is the name of the type INSIDE the event refnum. You can rename the outside wire all you want.
> That changing of the output label is essencial since it is the label name that shows up in the event case.
No it isn't. The label name that shows up in the event case is the name of the type INSIDE the event refnum. You can rename the outside wire all you want.
Then how do you explain this?
Edit: When I say label of the event case, I am referring to the case selection bar. Notice that it follows the name of the terminal, not the name of the data inside of the reference.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
The User Event creation is also a bit special in that if you create an Indicator directly from the output terminal, it will be labelled "user event out" but if you first bundle it and then create an indicator, it will retain the label of the data wired to the input within the cluster. Queues and notifiers don't retain the name in ANY situation.
Even more interesting: To More Specific, To More Generic, Type Cast, Unflatten from String and Preserve Run-Time Class all behave the same as Create User Event : maintaining the label when bundled, ignoring the name when directly connected. How's that for a bit of rare LabVIEW trivia?
It would seem that the majority of primitives which utilise wired inputs for their TYPE ONLY have with the exact same behaviour as "Create User Event". I would argue that "Obtain Queue" and "Obtain Notifier" fall into the same category and also that "Obtain Queue" and "Obtain Notifier" are actually the outliers.
PS Add Dynamic FPGA Type Cast to the list of supporting primitives.
PPS Add Read from Binary File to the list also.
PPS Other functions go the opposite route, when creating indicators directly they have a label and when bundling and then creating indicators they lose their label altogether. Cast Unit Bases is one such example.
That is what we have been trying to convince you of.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Sorry, crossrulz ... the original idea was to make the name of the queue and the terminal name match. That was coloring my understanding of your comments.
@AristosQueue (NI) wrote: RavensFan: Why doesn't your argument apply to every terminal in LabVIEW? What makes the queues (or the user events) special?
Good question.
My problem is that I don't know of any easy way to define the name of something like the queue reference wire. If I'm doing what I'm supposed to, I'd be using a typedef for my cluster. But wire that cluster into the Obtain Queue, I only get the generic "queue out" name. Now I can go and make a cluster of all of these queue references I want to bundle together (that way I can transport them around the VI easily or into subVI's where I'll unbundle the specific queue I want.) But I am using typecast to rename those queues. I could use a typedef for the sake of the queue reference. But if I go and modify my original cluster to add another element to it, would that change in the typedef propagate up to the queue reference typedef whose datatype is defined by the the original typedef?
Interesting ... so the name of the "queue out" terminal should actually follow from the name of the *element* input, not from the *name* input?
@crossrulz wrote: That is what we have been trying to convince you of.
I didn't think of it that way originally, but that is what I'm looking for too.
I could have a cluster that I name MySpecialData that I could wire into an Obtain Queue. The queue reference out would then be called "MySpecialData Queue" or "...queue ref" or ".... queue out"> I could have another cluster called MyExtraSpecialDAta that wires into an Obtain Queue and the reference wire would be called "MyExtraSpecialData Queue". Bundle these together with a regualr bundle and the cluster would automatically consist of those two references by those names. When I unbundle later, I would know exactly which queue reference belongs to what.
Since the cluster element name is defined at compile time, you shouldn't have the problem of a wire name changing like if you have a control or case structure or something defining the string data that is going into the Obtain Queue being a run-time decision.
Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Queue-name-bundle/idc-p/3143309#M31099