LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Get Queue Status function return elements default is set to = F. Should be set to = T.

Status: Declined

Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.

The Get Queue Status function will return all the elements in the queue - if you remember to set the "return elements" bool input to True. It's set to F as default. Why would I not want all the handy information from Get Queue Status but not want the elements? Smiley Indifferent


LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Active Participant

Perhaps it has something to do with memory? I really don't know, I don't use queues as often as I should.


If it defaults to False, then I assume labview has to do less work when the program runs.

Active Participant

I understand your point. Maybe it's my lack of understanding of how LV manages data output from primitives. However, the data are already present. And if you don't want the elements (and don't hook up a wire or indicator to the output) LV would not have to do anything differently.


LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Knight of NI Knight of NI
Knight of NI

I'm voting for this because even though I'm already used to it, I agree that this is a mistake which is way too easy to make.


That said, if the change is made, then the primitive should have additional code which sees whether the elements output is wired or not and only takes the elements if the input is T AND the output is wired.

Try to take over the world!
Active Participant

I often use the Get Queue Status to check if an element has been dequeued by the recipient (handshaking), or to monitor the number of elements to determine when to dequeue all elements (queue as buffer). In neither case do I want the elements themselves. Since the elements also remains in the queue, an actual data copy takes place if you use Get Queue Status to peek the queue. This can be expensive.


But the primitive should definitely have an internal check to save the data copy if the elements output isn't wired and return elements? is set to True (no matter the default value of return elements?).




CLA, CTA, CLED & LabVIEW Champion

I typically use get queue status to get the number of elements in the queue.  Then I compare this number to an outragiously large number and alert the user if it gets too large (i.e. something is wrong).  It makes for a nice bit of error checking in another loop.  I'm not sure I've ever changed the return elements input to true.


I agree with tst.  Ideally it seems like if the elements output is wired it should return the elements.  Otherwise it shouldn't.


Edit: It looks like SteenSchmidt beat me to most of these points.

Proven Zealot

As the designer of the queue prims, let me chime in on this.


Copying all the elements in the queue is expensive. You have all the elements in the queue and you make a duplicate of all of them when copying out for the Status primitive. That takes time and memory which is undesirable if you don't actually want the elements.


If the terminal is unwired, obviously LV does not need to make this copy.  When we were designing those prims, our first design had that. What we found was that there were cases where someone sometimes wanted the elements and sometimes not, and deciding based on whether the terminal was wired or not was a poor solution because that meant dropping a Case Structure and putting two copies of the Queue Status prim, one in each frame, where one was wired and the other wasn't. Ugly. So we introduced the boolean terminal.


I don't have a clue why we picked False for the default value. I just don't recall. It's something that could be changed in future LV versions if we mutated existing VIs to compensate (it's a bit harder than just creating an input boolean to preserve the input value; we'd also have to do something if someone does have the elements terminal wired for some strange reason). If you wire the terminal, then you would get the elements by default, which does, I admit, seem more reasonable. This would not create any performance hit for anyone who left the terminal unwired since the terminal being unwired would still be a reason to not copy the elements.

Active Participant

To me it makes perfectly sense to have it default at False. Most often when I use this function I want the que info, not the elements.  I would not want to spend any processor time or memory on generating that output when it is not needed.


The fact that you can get the elements out this way is not obvious enough to make users think that they should get it without any action. The compiler might rationalize the operation so that it would not matter if the default was true when the output has not been wired, but it is still logically cleaner to keep it at false.


I would agree that it would be useful to have a Preview function that returned all the elements though. Just remove that possibility from the get info operation (handle backwards compatibility the same way file operations did when they changed) and add a preview all function (or expand the functionality of the existing preview function (with a length input?)).

Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Proven Zealot

Separating into two separate primitives opens the door to race conditions in those times when you wanted the full state of the queue.

Active Participant

Yes you would not be sure that the state you read with the get status was still valid when you read the data.

Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Trusted Enthusiast

My gut reaction is no for one simple reason. Changing the behavior of these prims will alter existing code. I don't mind development functionality being changed. But when it comes to altering runtime functions it kind of spooks me. Aristos Queue's comments make me feel a little more comfortable about this particular one.


So kudos!

LabVIEW 2012