I was just working with User Events today and realised that the name of the User Event IS reflected by the name of the data connected to the "Create User Event" primitive whereas a Queue does not.
Is there a reason for this discrepency because I think the user is basically asking for what the "Create User Event" primitive does....
Since queues can be acquired by name, using the name of the data type could lead to some interesting conflicts. Still, that might be an interesting compromise.
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
But it's the name of the REFNUM we're talking about here, not the name of the QUEUE itself, that's a different matter enitrely.
I originally thought the same thing, but even the example you posted where the refnum is renamed by casting does not affect the Queue name, only the Refnum name. I don't see where name collisions should take place.
I personally think the behaviour of taking the wire label at the input as the Refnum name (not queue name) is better than the current implementation where every queue refnum is labelled "queue out". This would essentially solve the OPs problem.
Wait... Intaris, I just re-read what you wrote... let me investigate further. I thought you were talking about the name of the internals of the event. Please hold...
I'm not sure why the Create User Event would take on that behavior. I would've called that a bug if I'd noticed it before. Obviously not going to change it now, but I have no idea why it would do that. Seems like someone got overzealous in setting up type names. Primitives generally don't do that. The output of the Add primitive is "x+y" regardless of what is wired to it.
Regardless, the user's problem is that he wants to use the text of the value of the string, not the label of the string to name the output... following the Create User Event pattern still wouldn't match what Briton requested.
But given the User's shown piece of code, the Label of the string constant is just as static (and known at Compile time) as the content of the constant. It's just a case of him then setting the label of the input constant and he has what he wants. If he truly wanted the name to be different based on run-time changes to the contents of that input to "Obtain Queue" then he needs to re-think a lot of things.
Why would this behaviour of the "Create User Event" be considered a Bug? I think it's very useful indeed and was actually surprised that the Queue primitive did not do the same thing. Is there really any value of having the output wire always labelled "queue out"?
I agree that the Create User Event is NOT a bug. That changing of the output label is essencial since it is the label name that shows up in the event case. Imaging having 10 user events whose names were all "User Event Out". We would have no clue which event's case we were editing. Having the Obtain Queue do the same thing seems quite reasonable to me.
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
OK, here's a scenario where this behaviour irks me.
When implementing an event-based API for a process, I like to include "query" events where the caller sends a notifier as the content of the Event whereby the receiver simply puts the requested value in the notifier. The caller can then retrieve the value and destroy the notifier.
This requires me to create a User Event with a Notifier as datatype. When connecting the output of the "Obtain Notifier" to a "Create User Event" they all are called "Notifier out" which doesn't really help distinguishing the individual events. I need to force a rename on each and every User Event in this manner. If the Notifier would auto-name like proposed, this problem would go away.
Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Queue-name-bundle/idc-p/3143309#M31099