Issue with adding an activeX Container to a class

[Shad]

Hi,

I need to develop an object oriented application and use the ThorLabs TDC001 DC Servo Driver, which is an activeX software. To do so, I have to add an activeX Container to a class. When I create a class and try to add the activeX Container as a data member of the class, I am running into “Front Panel Error: extra controls on custom control’s front panel”.(Screenshot)

I appreciate if you let me know how I can work around the issue.

Thanks,

[smercurio_fc · Accepted solution]

Containers only make sense for GUIs. For a class you need to use an ActiveX reference control (a.k.a. Automation refnum control in the "refnum" palette).

[Shad]

 Thanks a lot. it works.

I am wondering why I can use the "refnum" as a private  data inside the class cluster. Please let me know how I can use it as a public data member. 

Thank you,

Shahed

[smercurio_fc]

I'm not sure I understand your question. In LabVIEW the items in the class data control are private, by definition. If you need to read/write to a specific member you would create an accessor function that's public.

[Shad]

Hi smercurio, 

Thank you for your reply. Correct me if I am wrong. You meant there is no either protected or public  data member in LabView, and all the data members must be inside the cluster frames, which would be considered as private. I need to create dynamic function (public) if I need to manipulate the data out of the class. if it is true, what would be the advantage of inheritance in LabView?

Regards,

Shahed

[smercurio_fc]

Well, you're actually talking about two different things here. The one issue is the ability to have public member of a class. There's basically two schools of thought on this: (a) it's perfectly fine, (b) it's a really bad idea. The (b) camp believes (among other things) that no member of a class should be public since that means that there's no way to safety check writing to class members. The (a) camp believes that for simple datatypes this is really a non-issue. I don't really know the rationale that NI had for making class members private, but I can't say that I disagree with it.

The other issue is inheritance. This doesn't really have to do with public/private members. It has to do with using a class as a starting point for another class. The new class would still need to access the members of the inherited class through the inherited class methods.  You can see how this works by looking at the "Dynamic Dispatching" or "Graphics" LVOOP examples that ships with LabVIEW.