Determining caller in Queued Msg Handler

[Oldbhoy]

Hi all,

As the title implies, i'm using a Queued Msg Handler to pass msgs between an event-driven loop and various other while loops controlling hardware.

I was wondering, is there a standard method to find out from the information passed into a message handling loop from the Queue, where the call has come from?

I have some message handlers which are called by various different UI elements, and my strategy for determining where the call has come from was to bundle the ctrl reference and whatever other information was needed into a type def and pass that as the message data.

There are other times however, when the same message handler has to be called at the end of a series of processes, but not necessarily with an accompanying UI reference. In this case I just leave it empty and include the data required.

Is this the usual strategy for dealing with multiple callers to a single msg handler, or is there a better way?

As usual thanks for the help. Am learning something new about labview every day, it's a very unique way of programming and I really like it, but fear i'm missing the subtleties sometimes

[cbutcher · Accepted solution]

I'm not exactly sure if I've understood correctly, so rather than directly answering I'll make some hopefully related observations:

• Queues can't tell you anything about where Enqueue Element was called
• Your queue datatype can be anything you want
• As you've already found, this can include bundling additional information (such as a string, enum, control reference, etc)
• Actor Framework (perhaps more than you need, but mentioning anyway) is an example of a Queue-based message handler system in which the datatype is an object with a dynamic dispatch method (Do.vi) 
  • You can use objects as your data type - and you can create inheritance hierarchies between different messages if you wish
  • This could allow you to do something like AF, where each sender uses a different child class
  • You could just use Actor Framework - it doesn't have to take over your entire application (recently I read someone suggesting that it should only be a small fraction of your classes that are Actors/AF messages in a typical AF application)
• If you don't require so much handling, you can just pass some "unique" element (e.g. enum, string) with your data to tell you where it came from

Does that help at all?

[johntrich1971]

I think that it really depends on why you need to know where the message originated. I find that in most cases the origin of the message is irrelevant. I pass any necessary data in the message data, and include the logic in the message handler to decode the data for each particular message type.

[Kevin_Price]

I'm with johntrich1971.   It isn't typical for a message handler to need to know the message's origin.  In cases where several parallel loops want to deliver *similar* messages with distinct meaning (for example, "New Data"), I would make distinct *messages* as needed.  For example, "DAQ Data", "DMM Data", etc.).

-Kevin P

[Intaris]

Well, what I do sometimes is include a notifier reference in the Queue datatype for a return path. The receiver does whatever it does for a given command and the result is passed back to the caller via the Notifier.

On the sender side, after sending the command via Queue, it waits for the Notifier to return data, indicating that the receiver is finished doing its job. You can wait for the notifier immediately, or do something else in the mean-time, or not send a valid notifier at all and not have to wait on anything.

This way the receiver knows nothing about the sender, but does know how to send data back to it.

[Kevin_Price]

The suggestion from Intaris may turn out to be even better for your app, given your talk of passing control references for the receiving-side message handler to work with.

His idea is often referred to as a "Self Addressed Stamped Envelope" approach or SASE.  That'll help you search and learn more.

-Kevin P

[cbutcher]

---

@Kevin_Price wrote:

His idea is often referred to as a "Self Addressed Stamped Envelope" approach or SASE.  That'll help you search and learn more.

---

Not to hammer away at the Actor Framework stuff, but the Reply Message works the same way (so take a look if you want an example of this)

[Oldbhoy]

Guys, thanks you so much these are all great answers (which makes choosing one as the accepted solution a bit tricky 😛 )

As most of you suggested, the easiest way to deal with this is simply to have distinct messages for each condition. I'm tempted to look into actor framework at some stage as well, but for my current project i probably dont have time, unfortunately. Might take me a while to become familiar enough with it to implement anything complicated

[cbutcher]

---

@Oldbhoy wrote:

Guys, thanks you so much these are all great answers (which makes choosing one as the accepted solution a bit tricky 😛 )

---

Well, I'm happy to receive an "accepted solution", but I will point out that if you feel multiple posts are "the solution(s)" to your problem, you're not actually limited to choosing one...

It is better to avoid choosing many, but it's not limited to just one.