LabVIEW probes with XControls of classes

[gb119]

Ok - this is somewhere between a bug and trying out a new feature...

I have a LabVIEW class that contains in its private data a couple of arrays. I want to be able to probe these arrays and to do this to display my data sensibly needs a little bit more than just the standard probe of a class. No problem - I also have an XControl that works for my class and does all the nice formating that I want, so I create a probe which uses my XControl...

Now, I can't add my XControl to my class, but I can live with that, but I can add my probe to my class and in fact if I want to make my class know that that is the preferred probe for it, then I should do this because then I can set the probe with the class properties.

So, I add my probe to my class in the project view. Whereupon my class promptly becomes locked - why ? Well the best answer I have is that the XControl on my probe has become loaded into memory and therefore the class is now open in two application instances - the one that I was editing until it got locked and the XControl's facade.

Aside from the fact that it really isn't obvous to the user what has just happened, the real killer is that because the class is now locked you can't remove the probe vi from the class to regain an editable class. All you can do is to close the class window quickly and hope you haven't saved it. If you have, then your only option is to open the ,lvclass file in a text editor and removed the offending probe from the class.

I think this is what is technically known as a catch-22 or perhaps "shooting yourself in the foot". Obviously the best solution would be if it didn't happen at all, the next best thing would be to make it a lot harder to produce a locked class.

[JonBowers]

Hi Gavin,

Is it possible for you to post the code that reproduces this problem. I would say this is most likely expected behaviour but it would be nice if it warned you about it first.

Regards

Jon B
Applications Engineer
NI UK & Ireland

[gb119]

Ok, adding the actual code I used would be a bit unwieldy, but here is a test case example that demonstrates the effect. It has a library which contains a class and an XControl of that class. Outside the library there is a demo vi and a custom probe.

If you open the demo vi and probe the class wire with my custom probe then it gives you a (marginally) prettier view of the class data. Doing this will lock the class, but that is expected as I have a probe open which is accessing the class, so no big deal. I can still edit the class if I close the probe.

Now suppose I want to make my custom probe the default probe for the class, so I need to add the probe to the class.

With just the project window opne, I drag the custom probe vi and drop it onto the class file in the project window. Hey presto, one locked class and no way to undo the damage from within the development enviroment. Thank god NI used a text based format to store the class meta-data - at least I can fix it with notepad and an understanding of how XML works...

[billings11]

Is this in 8.2 or 8.5, because I've seen a number of problems with probing classes in 8.2 just like this.