From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

DQMH Consortium Toolkits Discussions

Showing results for 
Search instead for 
Did you mean: 

Probe DQMH queue status

Go to solution

I would like to probe the MHL queue to see what is currently queued up.  A custom probe would work but I can't create one as the DQMH message queue  wire class/reference is private.


What is the quickest way for me to find out a DQMH queue status ?


0 Kudos
Message 1 of 5
Accepted by topic author Peter_B

As a general rule, any time you need to mess with the DQMH message queue beyond enqueue/dequeue, that's considered a code smell. If you're previewing the queue, or flushing the queue, you are likely doing something wrong. Not always, but usually. That's why it's not built-in, and it requires you to really commit by implementing a child class of the DQMH Message Queue class. You can have your own "Create Message Queue" VI that you call at the beginning (instead of the built-in Create Message Queue VI) that outputs your child class queue. And then your child class would implement a method that allows you to preview the queue.


But in my opinion, you should maybe take a step back and see why you want to preview the message queue in the first place... maybe there's something in your design that should be re-examined.

Message 2 of 5

Thanks Darren.

I know I have something wrong in my code design but to help me understand what I have done wrong and to facilitate me debugging it I would benefit from seeing what is queued up.  LabVIEW in general permits me to preview a queue and that functionality is helpful for debugging purposes.


The method you advise for me to implement the probe might be a slightly higher bar than me debugging it another way.  


0 Kudos
Message 3 of 5

I found my bug by probing the dequeued commands using a string history probe.  


Would I have benefited from a Queue preview feature to debug the MHL faster ?  Possibly.  The idea of limiting the scope of debug-ability of the MHL's queue in order to enforce best design practice is a reasonable goal.  It comes with a trade-off.  e.g. if I am able to make mistakes I also would like to be able to find those mistakes easily or in ways I am used to in LabVIEW.   But, I think I have now learned that private code is not intended to be probed too deeply !

Message 4 of 5

@Peter_B wrote:

I found my bug by probing the dequeued commands using a string history probe.  

That's the same debugging mechanism I use to figure out message ordering issues in QMH-based apps.

Message 5 of 5