DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Probe DQMH queue status

Solved!
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.

Peter_B_0-1699945364224.png

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

 

Peter
0 Kudos
Message 1 of 5
(815 Views)
Solution
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
(788 Views)

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.  

 

Peter
0 Kudos
Message 3 of 5
(757 Views)

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 !

Peter
Message 4 of 5
(712 Views)

@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
(674 Views)