1 pointHere's a VI that shows how to do the same thing, but with public properties/methods. Saved in LabVIEW 2012. Get Owning Project Name.vi
1 pointOver the past 5 years, each year, approximately: B -> C -> A -> B -> B tl;dr -- does not solve sufficiently painful problems efficiently enough. A few inconveniences that come to mind: Inability to designate an XControl as a view of an LVOOP class Inability to expose VI Server API of composed elements, other than through a naked ref getter on the XControl API, or re-implementing a wrapper Inability to override VI Server API methods/properties of composed elements Handler in Façade does not actively handle incoming User Events (just VI Server events) It feels like they were both released and EOL'd the same day (this is just perception, yet it plays a substantial role considering ROI in this technology) They're still super cool, and I would not recommend against developing an XControl. (I've developed perhaps a dozen?) It's just one of those tools in the toolbox that's not rusty, yet not often reached for.
1 pointI've used Digi devices for years, with few issues. Biggest system to date has four Etherlite 160's (total of 64 ports); sixty ports are tied to UUTs spewing 6400 char/sec each, all of which is digested by my LabVIEW application. The other four ports are used for instrumentation, doing query/response (a few dozen chars per message, as fast as the instrument responds). These terminal servers are setup to use the Digi RealPort driver, which provides standard Windows comm API, so VISA treats them like local asynch serial. When you get up to this level of activity, with array-launched VI clones, and lots of queue/notifier/event structure support, you have to be pretty careful about the details. Seemingly minor changes to cloned code, reentrancy settings, execution system assignment, etc can mean the difference between a working app and a quivering heap of unresponsive code. Dave