How to remove actor from project, if the class does not exist in disk anymore

[Blue_Perfect]

I expected to be able to get rid of unneeded actor classes in project hierarchy just by deleting them from filesystem, and then just ignoring the load errors when loading the project.

Apparently this isn't so, or at least I couldn't find a way to do this. Google gave no answers, so maybe we fix that here.

I had some unneeded classes in my project, so I deleted them. When I load the project now, the LabVIEW 2013 IDE keeps asking for me to locate the classes in filesystem, and when I can't, the classes will stick to projects dependency list although they have no callers. The dependency probably arises from actor class, as these deleted classes have been inheriting from it.

As these actors are unneeded, I can run the application in development environment without problems, but any attempts to build an application fail due dependency errors.

I realize that the *correct* way of going about this is to first remove the (to be removed) actor classes from inheritance hierarchy, prior to removing them from project, and only then removing them from the filesystem.

I still have that option, as I can take the classes from trash and tinker my way around this problem but I'm looking for a robust solution for this.

Anyone?

[stbe]

the class will show up in your dependencies

there, you need to remove the inheritance from the Actor.lvclass, then you can get rid of it.

[Blue_Perfect]

With (Not loaded) status, I can't find any obvious way to remove the inheritance to actor class. Can you give me a step by step example perhaps?

[stbe]

that looks strange.

I did a few (maybe too simple) tests where I could not reproduce this behaviour.

can you check "Why is this item in Dependencies?" - what does it say?

somewhere in your project you still refer to the deleted classes. unfortunately, you need to get rid of all of them.

OOP (more exactly lvlibraries work a bit strange here - you might have noticed that even renaming/moving class/lvlib-items offline - not in the project - causes undesired behaviour)

cheers

[Blue_Perfect · Accepted solution]

Thank you -stbe-

My earlier assumption on the dependency reason was incorrect. I had the class controls of these missing classes in disable diagram in the actor core . Your suggestion led me to find those, thanks for that.

And, yes, I have noticed the undesired behaviour of OOP on several occasions. At times it's somewhat demotivating, but I'm still quite happy with the actor framework.

With lvlibraries I've had no problems, but I'm just starting to use them. This is my first touch on both, actor framework and lvlibraries.

And now my builds work again

[CaseyLamers1]

Just a couple tips based on the last reply.

Keep typedefs out of your classes. They will pull that class as a dependency wherever you use that control. The exception is data that you expect to only use internally to that class.

Use of lvlibs is convenient with AF as you can group all of your messages with the actor. However, and maybe someone else can speak up to this, extensive use of libraries in a large project can significantly slow down the development environment and the build time.

Casey

[AristosQueue (NI)]

CaseyLamers1 wrote:

However, and maybe someone else can speak up to this, extensive use of libraries in a large project can significantly slow down the development environment and the build time.

niACS and I decided that the use of libraries to keep messages organized and to provide scoping abilities for messages was sufficiently valuable that such libraries are the default for the AF project plug-ins for LV that niACS made available. It adds some weight to load time of the project but doesn't appear to significantly weigh on development time compared to weight of the actors themselves.

[Blue_Perfect]

Thanks for the tips Casey, I was oblivious of the enum & class dependency marriage.

Thus far my classes have usually been free of typedefs, mostly because my relationship with them typedefs hasn't always been a happy one and I tend to mistrust the ease they bring.

Having said that, I do use them whenever the typedef use is contained in well defined part of the application.

I now look at lvlibraries with the same mistrust