ElijahKerry

Forgive the stupid question, but is this a setting you changed in Windows or in OS X? It's fantastic to hear that someone finally got to the bottom of this! I'm having a little trouble figuring out exactly what you did though - forgive me for being slow...

I'm seeing the same issue myself - in fact, I had to give a QuickDrop demo in Boston this week using a PC because I couldn't figure out a solution. I'm pretty sure this isn't LabVIEW's problem, so I'm not going to ask R&D to dig into this (yet). That being said, I can't find any settings in Parallels 7 that appear to fix this. Anyone give Parallels 8 a shot yet?

Matt raised several excellent points. In particular, he brings up a valid point about the UI loop and the use of references - sometimes the simplest approach is the best one, and it's probably more than adequate in your scenario to simply wire the data to the appropriate terminals as it arrives. I go back and forth on the use of references - it's certainly nice to be able to send commands from anywhere in the system to a single process than then knows how to display them, but allowing data to simply flow to the terminal is often more readable, easier to debug and definitely more performant. I tend to use references when I know I'm going to be using a lot of VI server commands to act upon the UI anyway, especially since it's best to decouple this from other processes. That being said, not using references will not mitigate the potential nightmare of a very large front panel. Depending upon how large you intend this panel to become, you should consider relegating logical groups of UI components to subVIs and displaying them in sub panels. Put generally, when you start thinking about having tabs, start thinking about a sub-panel too. Matt also brings up a good point about the use of classes to represent the different busses in your system. The command pattern is a simple way to bridge knowledge of traditional LabVIEW patterns like PC-QMH to classes, but the real power of OOP for LabVIEW users is when you have to represent multiple similar-but-different components of a system, such as hardware, measurements or in your case: busses. The real trick is determining where in the architecture of your system to abstract functionality such that these devices can be used through a common interface that can automatically take advantage of device-specific functionality under-the-hood. In your case, the generic command set would be defined by a base class and children would extend this by implementing the unique functionality for the bus they represent. I recently put together an example of using the Actor Framework to build a measurement and hardware abstraction layer system. It's a deep dive into Actor Framework, but this blog I wrote on the design decisions I made may still benefit you as you explore HALs. You might check it out if you have time and see if it yields any insights on how/where you would abstract components of your system.

PS: No such thing as too basic of a question!

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).