Leaderboard

I'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

Many of us would probably find that content interesting, but we aren't allowed to access it. Any chance you can share those presentations somewhere public, so that those of us who are not CLAs can learn from them? If not, could you please refrain from posting links to private communities in public locations?

How about giving the class a method called "Get Editor GUI" that returns a VI refnum, and if it returns Not A Refnum then it has no special GUI and if it returns a refnum then you run that GUI? In other words, instead of overriding the editor VI directly, override the accessor VI for that GUI.