Leaderboard

Update: I may not be changing this in 2015. This change turns out to have ramifications on various other aspects of classes, and there's a significant discussion about which way is the right way to fix it. When aggregated inside of a collection, handling NaN as NaN makes sense. But when aggregated as part of an object, it seems to make much more sense to treat NaN as data -- i.e. NaN == NaN -> TRUE. Having it return FALSE betrays the abstraction of the private data -- just because I use a double as my internal data and happen to use NaN as a sentinel should not change the external view of the object as a single coherent whole. Personally, I'm strongly persuaded by this argument and I'm doing further investigation into how other languages resolve this.

This is an old thread, but I was also working on some OOP probes. I can't offer much help in terms of the first problem (how to display massive amounts of class data), but perhaps I can help with the second issue (having to duplicate code). I'll share my efforts so far. Hopefully since the original post, someone else has come up with something more elegant. Here's the problem I'm trying to solve: Basically, I have tons of abstract classes that end up being wires on the block diagram. During execution, I'd like to take a peak using a probe and see what's going on - but even though the wire is an abstract class, of course there's some concrete class that's running through the wire during execution. I couldn't find a way to do a direct dynamic dispatch probe, so instead I created a simple "plugin" framework: 1) Created a probe for the abstract parent class. 2) Put a Subpanel on the probe's front panel. 3) Created a dynamic dispatching "Probe Facade" method for the abstract class, which takes a Subpanel reference as an input. 4) Dropped the Probe Facade sub-VI in the probe block diagram, inputting the reference to the Probe's Subpanel. Probe Facade MUST be overridden by the child class. The parent Probe Facade must also be called in any override. The default behavior is to simply insert Probe Facade's front panel into the Subpanel reference. The extended behavior of each override is to read any child-specific private data and display it on its front panel. The probe and Probe Facade VIs all need to be reentrant to probe multiple wires. Now for my case, I wasn't especially interested in inheriting a default Probe Facade appearance from a parent class, because my parent was abstract. But I don't see why with a little modification you couldn't create some default Probe Facade and have children override only as necessary. Perhaps this takes care of the "busy" work that Brian referred to in the original post? Though I may have misunderstood what he was concerned about in that case. My solution works most of the time, though I have noticed some inconsistent behavior if I have multiple probes active. Sometimes it looks like the Probe Facade errors out while initializing itself inside the subpanel. It's not super repeatable, though, so it's been tough to debug.