Is QMH obsolete? Am I wasteing my time?

[garthenar]

I've been studying & Implementing NI QMH in my programs but I've realized that there's a lot more interest and sources for the DQMH. If I jump into DQMH before I'm any good at regular QMH will I regret it? Or, am I just wasting my time learning QMH before DQMH?

I just need some guidance from someone who can see the bigger picture.

Thanks.

[billko · Accepted solution]

QMH is a basic pattern.  DQMH greatly expands on it.  I suppose it's up to you to use the right tool for the right job.  You don't need a chainsaw to prune your rosebush - but you don't want to lop a branch off with some garden shears, either.

The more complex your needs, the greater the dividends are using the DQMH.

That's just my opinion.  Maybe people with more experience with the DQMH will show you that it's easily scalable to simpler needs.

[garthenar]

---

@billko wrote:

QMH is a basic pattern.  DQMH greatly expands on it.  I suppose it's up to you to use the right tool for the right job.  You don't need a chainsaw to prune your rosebush - but you don't want to lop a branch off with some garden shears, either.

The more complex your needs, the greater the dividends are using the DQMH.

That's just my opinion.  Maybe people with more experience with the DQMH will show you that it's easily scalable to simpler needs.

---

Thanks billko, that helps a lot

I think I'll keep l going with QMH for the time being and move onto DQMH later (after AE's but befor AF). At my level garden sheers will get me a long way. And basic is better since I'm working on other concepts too.

[billko]

I hope more people comment on the topic.  I'd like you you to get a better sample size.

[johntrich1971]

I agree that learning the QMH is worthwhile. I have found my own variations of it to be adequate for most applications. You will find people who swear that lots of different design patterns are best (DQMH, JKI State Machine, Actor Framework, just as a few examples). All of these are good design patterns, but the tool does really need to fit the task. You don't generally need a sledge hammer to drive a nail. 

You mentioned AF (I'm assuming that you were referring to Actor Framework). I would recommend that you have a good grasp of how classes work in LabVIEW before attempting anything in Actor Framework. I have found myself moving away from Action Engines in favor of class methods.

[RTSLVU]

I say YES QMH is obsolete    

IMHO: QMH was a horribly over complicated design pattern to begin with. The invention of Channel Wires a few years ago and the corresponding CMH design pattern have made QMH and (dare I say) Queues themselves obsolete.

Multiple Channel Wires are far easier to understand and make a lot neater easier to follow block diagram than multiple Queues and Notifiers. 

Here's an example of a CMH project

[crossrulz]

---

@RTSLVU wrote:

Multiple Channel Wires are far easier to understand and make a lot neater block diagram than multiple Queues and Notifiers.

---

If you are referring to the actual reference wires, I would agree.  I find it easier to contain the QMH in a library.  Private to the library is an Action Engine which maintains the queue.  I then have public methods that use the AE to send specific messages to the QMH.  So what this does for me is I do not have reference wires running everywhere.  I rely on the icon of the method and/or a look up string to tell me where the message is being sent to.

[johntrich1971]

---

@RTSLVU wrote:

I say YES QMH is obsolete    

IMHO: QMH was a horribly over complicated design pattern to begin with. The invention of Channel Wires a few years ago and the corresponding CMH design pattern have made QMH and (dare I say) Queues themselves obsolete.

Multiple Channel Wires are far easier to understand and make a lot neater easier to follow block diagram than multiple Queues and Notifiers. 

Here's an example of a CMH project

---

I've not tried channel wires, but to me they just look like messy ways to implement queues. 

[johntrich1971]

---

@crossrulz wrote:

---

@RTSLVU wrote:

Multiple Channel Wires are far easier to understand and make a lot neater block diagram than multiple Queues and Notifiers.

---

If you are referring to the actual reference wires, I would agree.  I find it easier to contain the QMH in a library.  Private to the library is an Action Engine which maintains the queue.  I then have public methods that use the AE to send specific messages to the QMH.  So what this does for me is I do not have reference wires running everywhere.  I rely on the icon of the method and/or a look up string to tell me where the message is being sent to.

---

I generally use a similar approach. I like to store my queues in classes, and wrap them in methods that tell which queue to use.

[RTSLVU]

---

@johntrich1971 wrote:

---

---

I've not tried channel wires, but to me they just look like messy ways to implement queues. 

---

Messier than Queues? LOL okay... 

Communicating Data between Parallel Sections of Code Using Channel Wires