04-11-2017 11:34 AM
Is there a strong reason to not show the timeout option for your queue system in DQMH?
We do use the timeout case, especially on some RT systems. So right now we just add the timeout to the dequeue message VI but with every update and new computers the code is broken for cases where the Timeout is connected.
So if there isn't a strong reason for not having it on the connector pane is it something you would consider changing for the next update?
Cheers
Henrik
Solved! Go to Solution.
04-11-2017 04:16 PM
Hi Henrik,
Our reasoning for not providing the timeout input is described in the block diagram of the Delacor QMH Dequeue Message VI, where it states: "Note that the Dequeue Element function does not have a timeout wired. In an event-drive framework like the Delacor QMH, generating messages with events is preferable to polling for a "no message" situation." followed by:
"Note: If you want to change the behavior of this VI, create a child class of Message Queue.lvclass and override this VI"
If what you want is to make sure that your code does something periodically, consider using instead a helper loop or message pump as described in this post.
You could create a child of the DQMH Queue, add an accessor in your override VI that would set the timeout to the dequeue. This should stop your code from breaking with every new update.
Of course, you can also add your feature request to this thread.
Regards,
Fab