Object probe can't be indicator, right?

[PaulL]

I'm sure this has been discussed already (maybe as part of the XControls as default control for class) but anyway, LabVIEW provides a handy view into the contents of a class in the probe window (thanks, NI!). Is there any reasonable way to put this on the front panel of a VI? (I think the answer is no, unfortunately. I'm hoping somebody can explain why. It would be really helpful if I could do that.)

Edit:

(I know I can convert the flatten the class to a string and extract the name of the parent class and the actual class. Hmm... maybe I can take that further. Maybe that's kind of the answer. Well, I don't think I can everything the probe does, though.)

[mje]

I have wished the same thing many times, but I don't think it's possible. I'd love to find out why...

The only idea that came to mind for me was parsing the flat data and generating a table of property values. Seemed like a lot of work though so I never really explored it much.

[Aristos Queue]

Nope, it can't go on the FP of a panel because that would enshrine private data as a public interface. As a control, that would make it possible to set private values in ways not allowed by the class API, leading to logically insane objects (i.e., objects whose private fields are inconsistent with each other according to the rules as defined by the class methods). As an indicator, that would be more acceptable, but it would still be showing the private aspects of a class which would be inappropriate for a typical user of the class (by which I mean a programmer who is using the class to write another program) to know about. We deliberately did not include this ability because, we thought, "Hey, we've got XControls, which address this problem!" The expectation was that XControls would be the means by which a class author defined the display of the contents of the class, displaying the information that was appropriate for a given class to display. Classes and XControls were designed simultaneously, and it turns out that the labor of building an XControl is extremely high, something we didn't really grasp until XControls had been in user hands for a couple years. We have played around with ways to change XControls to lower the labor costs, with minimal success. My own opinion -- and I haven't really discussed this with the rest of the team, so I don't know if there's consensus here -- is that we just need a whole new "something" for class authors who want to define the display, something with much lower labor requirements. That something is going to take a while to build, and working on the problem at all is, at the moment, a lower priority than other projects.

[mje]

Makes sense, especially on the control side.

As for the "something", I wholeheartedly agree. I realize XControls are ideal from a functional stand point, but the labor barrier to creating them has kept me from ever creating one in any context.

[PaulL]

Makes sense, especially on the control side.

As for the "something", I wholeheartedly agree. I realize XControls are ideal from a functional stand point, but the labor barrier to creating them has kept me from ever creating one in any context.

I agree with mje seconding AQ.

It would be nice to have something. Maybe the class designer can somehow make it private. I at least partially understand the security risk, though. (Don't probes have to have the same rules?) I'm sure there are lots of implications here I haven't yet pondered.

I also would prefer something other than creating an XControl for each class, only because my impression is XControls are complex enough to make me think twice about going down that road (but to be fair I've never made a really serious effort to build one for any actual project) and, more importantly, because I can't make them part of a class so I can't extend them easily (or at least such is my perception, which may be not entirely correct). (I'm guessing I can put OO code inside an XControl so probably it is possible to extend parts. I am completely out of my element here, though. Hopefully someone else will help out here with a better analysis.)

By the way, I've seen some super-cool XControls! I'm just not eager to have to create one for each class.

[ShaunR]

I don't think there is anything inherently complicated about creating Xcontrols any more than creating a class. The issue is though, is that you cannot inherit from a pre-existing control (class?). This is what makes it not worth the effort since even for a simple control (a numeric for example) all the existing properties and methods have to be re-written Instead of just writing the additional functionality.

Therefore you don't write all the normal properties and methods for that control type and end up with a specialised control, with limited functionality, which is only useful to you ( and even then, probably in only a couple of scenarios). However, if you could inherit all the properties and methods from, say, an x-y graph and just add a bit of code to add a trend-line. then that would be worthwhile.

[Olivier Jourdan]

I don't think there is anything inherently complicated about creating Xcontrols any more than creating a class. The issue is though, is that you cannot inherit from a pre-existing control (class?). This is what makes it not worth the effort since even for a simple control (a numeric for example) all the existing properties and methods have to be re-written Instead of just writing the additional functionality.

Inheriting from pre-existing control would be great. Re-writing code is not really an enjoying work. One "shortcut" I've done to solve this issue is to expose the reference of the facade.vi objects through XControl properties. Even if it's not the best solution, it allows you to access quickly to all properties and methods writing usual code.

This "workaround" has, at least, one lack, it not allows basic XControl user to modify properties righ-clicking on the object as he used to do with "classic" control.

In any case, having a way to choose properties/methods to automatically exposed to end user would be a great feature to add in next LabVIEW release