Leaderboard

Hey dmurray, Glad to hear you found the command pattern example useful. It was my first successful application using OO, so I created the manual in the hopes of leading others down a similar path. I took a minute to glance through your code, and one big question jumps out at me: are you actually passing data between these loops? One of the major reasons to use the command pattern is the encapsulate the data associated with a command inside of a class instead of passing it as a variant. Given that none of your classes appear to have private data, I can only assume that you aren't actually sending information between the loops. If my assessment is correct, the use of this pattern may be overkill - though there's nothing necessarily wrong with using it. However, your second question leads me to believe that you may actually want to pass information between your loops. Your UI loop already contains references to front panel items you might want to update upon receive data - ideally, it only updates the necessary component upon receiving new data. Rather than be free-running, it could respond to commands sent from other loops that contain the new value to be displayed. As an example, you would have a class to update a graph and the private data could be wafeform data and cursor information - any other loop who had access to the UI queue could then send a command to update the value of this graph. PS: Rather than increasing the scope of this loop as you add more UI elements, consider having sub-diagrams that load separate UIs with their own dedicated processes) Q3: One loop two sources is fine - in fact, it's what queues are best at. Even if you weren't using the command pattern, it's common to have multiple producers of commands/data pumping that information into a queue, which should only ever be dequeued in one location (ie: the consumer). The approach you've described for logging sounds appropriate Q4: A dialog should be treated like a free running process that has it's own P/C loops on the block diagram. For a good example of this, see the sample projects and how they invoke an options dialog. Finally, is this the right pattern? It's fundamentally a producer/consumer queued message handler (P/C-QMH), but we use OO instead of enums with case structures. As such, it's just as appropriate a as a regular QMH would be, but you're able to encapsulate the data you pass between the loops using classes (should you choose to do this).