Help with LV object constant

[jvh75021]

I am looking at a block diagram that needs updating and there is a cube shaped object there that has a red outline. When I hover over it the the context help says Properties, no description available and then Properties (Avionics.lvclass) then Private Data(cluster of 1 element), and under that GyroClass(cluster of 33 elements), then a long list of variables.

So it looks like some type of container. Still wondering exactly what it was I right clicked and the Cluster, Class, and Variant palette was available. There I see an similar object and it is called an LV Object Constant. Context help is available while I hover over the palette but not after I paste one on the block diagram so I grab the context help from the palette and it says "The LabVIEW Object is the common ancestor data type for all LabVIEW classes. You can use the LabVIEW Object to create generic methods that can handle all LabVIEW class data types". The detailed help says the same thing.

I looked in the development zone, tutorials, and code examples and cannot find any better or more detailed description. Could you point me to a source of information please? I am trying to find outhow and where it is created, where all it is used and how this "constant" is loaded.

Thanks,

jvh

[smercurio_fc]

That's a LabVIEW Class.

[jvh75021]

---

@smercurio_fc wrote:

That's a LabVIEW Class.

---

I opened the class from the context menu. There are dozens of vi's there as well as controls, and typedefs. So I do not see how this cube maps to the whole class. Nor do I see its elements there.

[Ben]

The ctl file (usually top item in the class) defines the private data of that class. If you open it you will what looks like a cluster with all of the fileds taht hold the private data.

If you can't find all of the elements you saw in the context help then you may have been looking at an instance of one of teh child classes that inherit teh private data from the parent class but also has its own.

I'll be that did not clear up any of your confusion.

Ben

[jvh75021]

OK, thank you both.

I have found the .ctl and under Browse Relationships I found 29 callers, one of them named loadProperties. 

Bingo.

jvh

[jvh75021]

---

@smercurio_fc wrote:

That's a LabVIEW Class.

---

Guess it wouldn't be practical for the help to show all the methods and typedefs associated with the class. But in the back of my mind I wonder why is this "class" an object and a vi is not? That is, I wish the help had told me what you did.

[Ben]

---

@jvh75021 wrote:

---

@smercurio_fc wrote:

That's a LabVIEW Class.

---

Guess it wouldn't be practical for the help to show all the methods and typedefs associated with the class. But in the back of my mind I wonder why is this "class" an object and a vi is not? That is, I wish the help had told me what you did.

---

 strictly speaking type defs and classes don't mix well. If you find your methods are applying changes to the wrong values, disconnect from the type def to get them to work.

You have been warned.

Ben

[dkfire]

How much do you know about Object Oriented Programming (OOP) ?

Have you ever worked with classes ??

To me it sound like you don't know anything about OOP.

Before you go any further, I thing it will be a good idea to read a little about OOP. Try searching the NI website for OOP.

[jvh75021]

---

@Ben wrote:

---

 strictly speaking type defs and classes don't mix well. If you find your methods are applying changes to the wrong values, disconnect from the type def to get them to work.

You have been warned.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This project has several large classes and each has directory containing several many typedefs.

Tell me more about typedef and class conflicts. Inquiring minds want to know...

[Ben]

Aristos Queue has warned me many time about type defs and that I should bit the bullet and go 100 % clases.

I have seen issues with type defs in classes not updating properly but the most recent type def issue invloved an type def'd enum that came from the NI motion stuff. When using an update method for the enum, LVOOP "missed" and applied the value to the next field in the private data.

I am not sure if I read him saying that here but most likely on LAVA.

I have been gradually converting to his suggestions and like the results since dynamic dispatching on genericlly classed classes let me switch to other versions with new class while the type def approach unfortunatley reslted in updates of the callers.

Keep in mind I am not a trained OOP developer and aside from some self-assigned reading, I have been teaching myself and would love people to steop on my LVOOP replies when I am wrong. So please speak out if any of teh above is bogus.

Still learning,

Ben