Using TypeDefs in a class

[Daklu]

So

[Daklu]

So I'm dipping my toe into the chilly waters of LVOOP and encountered something that doesn't work the way I expect. Is it a bug? Is it a 'feature?' Is Labview protecting me from my own idiocy?

In my class I have a vi that takes a cluster of data as an input. I would like this cluster to be a typedef that I could use internally in the class as well as have available to class users. However, any class vis that use the typedef as a input, as well as the typedef itself, break when the typedef is in the class structure. If I disconnect the typedef on member vis it works, or if I place the typedef outside the class heirarchy it works. Is this expected behavior?

Other questions I've been unable to find answers on:

-Is it possible to create a class or method as 'must inherit?'

-NI examples always show classes and lvlibs contained within a lvproj. Is there any particular reason for this other than being able to set up build specifications?

-Is it preferred/discouraged to put several classes within the same lvproj? i.e. I have a Battery class which will serve as a parent for several specific battery child classes. (i.e. Energizer, Duracell, etc.) Currently I am planning on putting them all in the same lvproj. Good? Bad?

[Justin Goeres]

QUOTE (Daklu @ May 19 2008, 07:35 PM)

In my class I have a vi that takes a cluster of data as an input. I would like this cluster to be a typedef that I could use internally in the class as well as have available to class users. However, any class vis that use the typedef as a input, as well as the typedef itself, break when the typedef is in the class structure. If I disconnect the typedef on member vis it works, or if I place the typedef outside the class heirarchy it works. Is this expected behavior?

Do you have the Access Scope for the typedef set to Private? You have to make sure it's Public (or Protected, if you're only using it in related classes) or else VIs outside the class won't be able to access it.

QUOTE

Other questions I've been unable to find answers on:

-Is it possible to create a class or method as 'must inherit?'

Not at edit time. However, I have created dynamic dispatch VIs that do nothing but return a "must override" error at runtime to accomplish something similar.

QUOTE

-NI examples always show classes and lvlibs contained within a lvproj. Is there any particular reason for this other than being able to set up build specifications?

Not that I'm aware of. You have to use the Project environment to create/edit classes, but they don't have to be members of an .lvproj.

QUOTE

-Is it preferred/discouraged to put several classes within the same lvproj? i.e. I have a Battery class which will serve as a parent for several specific battery child classes. (i.e. Energizer, Duracell, etc.) Currently I am planning on putting them all in the same lvproj. Good? Bad?

I put things into a .lvproj based on whether they're associated with that.... project . If the class was part of a reuse library (in user.lib or something) I might leave it out of a particular project file (just like I'd do with most anything in user.lib), but other than that pretty much any file that I use in a particular project goes in that project's .lvproj.

[Tomi Maila]

QUOTE (Daklu @ May 20 2008, 04:35 AM)

In my class I have a vi that takes a cluster of data as an input. I would like this cluster to be a typedef that I could use internally in the class as well as have available to class users. However, any class vis that use the typedef as a input, as well as the typedef itself, break when the typedef is in the class structure. If I disconnect the typedef on member vis it works, or if I place the typedef outside the class heirarchy it works. Is this expected behavior?

Without an example code I cannot say for sure what is wrong. However in addition to what Justin said, it may be that you are having some sort of type recursion that is not allowed.

QUOTE (Daklu @ May 20 2008, 04:35 AM)

NI examples always show classes and lvlibs contained within a lvproj. Is there any particular reason for this other than being able to set up build specifications?

The dependencies item in your project explorer shows all items such as VIs and classes that your project depends on. It's a must have for a LVOOP developer as you need to call your parent class methods and you can find them in the dependencies unless you have added all the classes in your project.

QUOTE (Daklu @ May 20 2008, 04:35 AM)

Is it preferred/discouraged to put several classes within the same lvproj? i.e. I have a Battery class which will serve as a parent for several specific battery child classes. (i.e. Energizer, Duracell, etc.) Currently I am planning on putting them all in the same lvproj. Good? Bad?

Project is a project. What ever you need in your project you put into your project. Don't put items you don't use in your project.

[Daklu]

QUOTE

Do you have the Access Scope for the typedef set to Private? You have to make sure it's Public (or Protected, if you're only using it in related classes) or else VIs outside the class won't be able to access it.

It's not a scoping issue. This happens when the typedef and vis that use the typedef are within the same class. (But yes, I did try rescoping it anyway. )

QUOTE

However in addition to what Justin said, it may be that you are having some sort of type recursion that is not allowed.

Hmm... that could be. I'm using essentially the same data in my typedef as I am in my control private data, though I'm not using the typedef as the control data. One that is annoying is the number of errors in the error list that spawn whenever anything goes wrong. It makes it difficult for me to figure out what the real problem is.

QUOTE

Is it preferred/discouraged to put several classes within the same lvproj?

I think the lingo is throwing me off a bit. Classes and Project Libraries use the Project Explorer but are not projects themselves--at least I haven't been considering them projects since they do not have a .lvproj file. Is this correct? The class hierarchy I'm developing is intended to be used by other developers in several battery testing systems. I intend the classes to be copied to the application directory rather than placed in user.lib.

On the one hand, these classes aren't a project in the sense that there isn't a complete application when finished. On the other hand, all the classes are related so having them in a lvproj makes it easier to manage the group. If I have the class tree in a lvproj, does another developer need to use the entire class tree or can they extract a single branch of the tree, assuming there are no sibling dependencies. (I'm thinking of the kind of restrictions that go along with project libraries... use one vi and you get them all.)

This really isn't a critical issue. Whether or not I place the classes in a lvproj seems to be a matter of personal preference. I'm really just trying to figure out if there are standards or best practices with this.

[Aristos Queue]

QUOTE (Daklu @ May 20 2008, 02:14 PM)

Hmm... that could be. I'm using essentially the same data in my typedef as I am in my control private data, though I'm not using the typedef as the control data. One that is annoying is the number of errors in the error list that spawn whenever anything goes wrong. It makes it difficult for me to figure out what the real problem is.

Open the List Errors Window. In the list of files, scroll to the very top. The items with a red X are the items that are really broken. Everything else is broken as a result of the red X items.

[Daklu]

I've resolved the problem. The root cause is one of the following, I'm not sure which:

1. The project file became corrupted or Labview got into some weird state that required a restart or reboot.
   
2. I had open control/project/vi files that had not been saved, thus breaking everything.
   

It was probably #2, meaning Labview was saving me from my own idiocy.

QUOTE

Open the List Errors Window. In the list of files, scroll to the very top. The items with a red X are the items that are really broken. Everything else is broken as a result of the red X items.

Thanks for the tip AQ, that has helped a lot.