no option to delete method from class

[PaulL]

I somehow ended up with methods that I am unable to remove from a class. Generally VIs in a class have an option to remove from project either from the larger project view or from the individual class. These last three seem to be an exception. (If I open the front panels of the VIs the title bars show the expected class:method format....)QUOTE(Paul_at_Lowell @ Dec 12 2007, 05:01 PM)

I somehow ended up with methods that I am unable to remove from a class. Generally VIs in a class have an option to remove from project either from the larger project view or from the individual class. These last three seem to be an exception. (If I open the front panels of the VIs the title bars show the expected class:method format....)

OK, I think I see. These are methods in what is functioning as an abstract class (they are overridden in child classes) so I can't remove them....

[Aristos Queue]

QUOTE(Paul_at_Lowell @ Dec 12 2007, 06:33 PM)

OK, I think I see. These are methods in what is functioning as an abstract class (they are overridden in child classes) so I can't remove them....

You should still be able to remove them. Post your VIs if you can and let's see if anyone else can replicate.

I tried removing a dynamic dispatch member that was in a parent class with an overriding child, and it worked just fine.

http://lavag.org/old_files/monthly_12_2007/post-5877-1197507260.png' target="_blank">

[PaulL]

QUOTE(Aristos Queue @ Dec 12 2007, 05:54 PM)

You should still be able to remove them.

http://lavag.org/old_files/monthly_12_2007/post-5877-1197507260.png' target="_blank">

Hmmm... and what's stranger is that I disinherited all the child classes and I still can't remove the methods....

Actually I stripped down the project to just this class. The child classes still show up under the items in memory (which they shouldn't unless I am totally missing something--well, in all fairness, one of them should because a subVI references it, but the others shouldn't). I tried to save the project but LabVIEW gave me an out of memory error. I do have an open support request with NI support on the larger issue to which this relates and NI Support has the entire project (much too large to post here).

[Mark Balla]

I just ran into this problem today.

Not sure if this is the same issue you are seeing.

I had two vis with the same name "Build FLD Record". One owned by a class and one that wasn't

If I were to remove the owned one from the class lvlib I would have two vis with identical names.

This would cause a conflict so it looks like LabVIEW won't let you remove a vi from a class if it will cause a conflict in the project.

When I closed the project and opened the class by itself the file could be removed from the class.

When I reopened the project as expected a conflict showed up.

Hope this helps

[Tomi Maila]

QUOTE(mballa @ Dec 13 2007, 09:13 AM)

I had two vis with the same name "Build FLD Record". One owned by a class and one that wasn't

If I were to remove the owned one from the class lvlib I would have two vis with identical names.

If this is the case then you can simply rename the VI you want to remove and then remove. What always works is removing items from a class by editing the .lvclass file with a text or an XML editor. This never fails

Tomi

[Aristos Queue]

QUOTE(Paul_at_Lowell @ Dec 12 2007, 07:18 PM)

Actually I stripped down the project to just this class. The child classes still show up under the items in memory (which they shouldn't unless I am totally missing something--well, in all fairness, one of them should because a subVI references it, but the others shouldn't). I tried to save the project but LabVIEW gave me an out of memory error. I do have an open support request with NI support on the larger issue to which this relates and NI Support has the entire project (much too large to post here).

What's the CAR for the open issue? I can look at the source code there.

[PaulL]

QUOTE(mballa @ Dec 13 2007, 12:13 AM)

I just ran into this problem today.Not sure if this is the same issue you are seeing.

Hmmm....yes, I think there is something like this going on, although it's quite confusing (starting with I'm not sure why the other methods are in memory at all).In the example you have it seems logical to me not to be able to remove the method from the class if both methods would remain in memory. In my case I don't know what is keeping the methods in memory, but there are such methods when I open the project. What I have at the moment is a much-pared down version of the full project. In my first post I show just the class in a project view. If I open the chopped-up project (I'm trying to isolate a larger problem) I have only this class remaining in the project, but the three methods include controls and indicators on a context class and invokes methods in that context class so that class is in memory. (I removed all the data and methods for that class, however, in the chopped up project--it used to have references to this top-level state and its now disinherited substates, though. I implemented the state design pattern. The first version was quite successful but I needed to add states because of functionality changes. More confusingly, the disinherited subclasses for the project class and their methods remain in memory. I'm not sure why that is, but maybe there is some link in the now-broken code that retains some memory of these?)QUOTE

What always works is removing items from a class by editing the .lvclass file with a text or an XML editor.

"Actually, I tried that. LabVIEW was too smart and put them back when I opened the project. I'm pretty sure LabVIEW was using the edited copy....QUOTE

What's the CAR for the open issue? I can look at the source code there.

I don't think there is a CAR. (Maybe this specific behavior isn't really broken--now I'm not sure. The larger NI support issue is 7178674. The larger issue involves two things--LabVIEW suddenly has started prompting me to save VIs it recompiles every time I open and close a project--which in my past experience has gone along with a corrupt project file, and a build for distribution crashes LabVIEW--or alternatively a save as on the project results in an out of memory error. I was adding, renaming, and editing subclasses and their relationships when the first problem occurred. I then found out the latter has been around a while--I just hadn't had a need to export the project before. It is possible, I suppose, that something like the following is going on, that relationships are being maintained in nonupdated nonfunctional code (????), but that is just a hunch. I haven't been able to determine what is going on.)PaulOK, I edited the chopped-up project still further.The three methods in the VentilationDoorState.lvclass have a couple subVIs that were formerly methods of the VentilationDoor.lvclass (the context class for the state pattern).1) If I delete the subVIs in the three VentilationDoorState.lvclass methods then only the VentilationDoor.lvclass (it's empty--no methods or data) remains in memory and all the former assoications go away and then I can remove the three VentilationDoorState.lvclass methods as expected.2) If, on the other hand, I leave a single subVI in the VentilationDoorState.lvclass methods (and this subVI used to be a method of the VentilationDoor.lvclass, so that it has a VentilationDoor.lvclass object in and out), even if this VI does nothing at all, then many things that used to be connected to VentilationDoor.lvclass stay in memory, even though there currently is no association whatsoever (or shouldn't be--I really can't see why any of these formerly related items should be in memory at all), so that LabVIEW keeps recompiling the methods and I can't export the project.I'm not entirely sure I'm not just confusing myself (maybe there is something going on of which I am just not aware), but this really doesn't seem to be expected behavior....

[PaulL]

Ah! It turns out I had missed a subVI, which in turn called a VI in another class, which in turn... so at least most of the dependencies should have been there. (I'm not sure how the disinherited state classes fit in, but they must somewhere.) :-)

I started from the last "known good" version and carefully worked in steps until I got to a version where I was always prompted to save each time I opened the project and immediately closed it. This time I promptly 'fixed' the code to make it executable, even if it didn't do what I wanted, and LabVIEW stopped prompting me to save. So in this case, at least, the save prompts weren't anything to be alarmed about--NI Support was correct there.

NI Support filed a CAR on the File...Save As issue.

As far as the starting topic of this thread, though, mballa's example seems to apply.