Daklu Posted January 24, 2010 Report Share Posted January 24, 2010 This has happened to me only a handful of times and I've forgotten what caused it last time I saw this. What would cause the option to remove a vi from a project to NOT show up in the context menu? There aren't any VIs that depend on this one. This VI does depend on a few other VIs that I have already removed from the project and are listed in the dependency section. Restarting Labview didn't resolve the problem. Any ideas? Quote Link to comment
Yair Posted January 25, 2010 Report Share Posted January 25, 2010 I don't know why the option isn't there, but here are some options: Move the file out of the folder or the library, then remove it. Open the class separate from the project, then see if you can remove it. Edit the lvclass file manually. Quote Link to comment
Daklu Posted January 25, 2010 Author Report Share Posted January 25, 2010 Thanks for the response Yair. I was able to remove the guilty files by deleting all the contents and resaving them. Still don't understand why I couldn't remove them in the first place. I wonder if it's a bug or expected behavior in certain situations? Quote Link to comment
Chris O Posted January 26, 2010 Report Share Posted January 26, 2010 I think if you have your project auto-populate from the directory, it doesn't give the option to remove from project. I seemed to have an issue like that once. I could be wrong. I don't have LabVIEW in front of me right now. Thanks for the response Yair. I was able to remove the guilty files by deleting all the contents and resaving them. Still don't understand why I couldn't remove them in the first place. I wonder if it's a bug or expected behavior in certain situations? Quote Link to comment
MikaelH Posted January 26, 2010 Report Share Posted January 26, 2010 But you can't use Auto-Populate folder within a class. Classes and Auto-Populate folders don't go togeather 1 Quote Link to comment
Aristos Queue Posted January 26, 2010 Report Share Posted January 26, 2010 If you use an autopopulating folder anywhere then all the contents of that folder will be included in your project. If an item is in a library (class/statechart/xctl/plain library), the item will be listed under the library, even if it is part of an autopopulating folder. This can lead to the autopopulating folder saying an item cannot leave the project but the item isn't listed under the folder, so you don't recognize this fact, because the item is under its owning library. Quote Link to comment
Daklu Posted January 29, 2010 Author Report Share Posted January 29, 2010 Auto-populating is a potential cause, but you'll notice I don't have any auto-populating folders in this project. (And I don't have any hidden away in other virtual folders.) I've been running across this more frequently the last couple weeks. I suspect it has something to do with renaming/moving classes and methods, but I don't have a repro case. Quote Link to comment
Aristos Queue Posted January 29, 2010 Report Share Posted January 29, 2010 I've been running across this more frequently the last couple weeks. I suspect it has something to do with renaming/moving classes and methods, but I don't have a repro case. No known CARs on something like this. I'm going to be more than a bit distracted for the next couple weeks, so if you do get a repro case, post it to ni.com so an AE can percolate it up... I may not notice if you just post to LAVA. Quote Link to comment
NATE Posted August 20, 2014 Report Share Posted August 20, 2014 I just experienced this with a method of a class in LV2013 SP1 f2. The other methods have a Remove from Library option, one didn't. No idea why. I renamed the method (since I was going to delete it anyway), and there's my menu item... Quote Link to comment
John Lokanis Posted November 13, 2015 Report Share Posted November 13, 2015 Came across this thread today when looking for a solution to this issue. This has been happening to me occasionally. I have not found a solution yet. I am not looking for a 'Remove from Project' menu item but rather a 'Remove from Library' option when trying to get rid of a method I no longer need. The offending method cannot be dragged out of the class. If I delete it, the class complains and I cannot remove the reference to it still. The only solution I have found is to hack the .lvlcass XML and manually remove any reference to the method. This definitely needs a CAR. I am seeing this in LV2015 so it is still broken. Quote Link to comment
JKSH Posted November 13, 2015 Report Share Posted November 13, 2015 This definitely needs a CAR. I am seeing this in LV2015 so it is still broken. I suggest posting to http://forums.ni.com/ -- I don't think there's that many official NI eyes at lavag.org. Quote Link to comment
Neil Pate Posted November 13, 2015 Report Share Posted November 13, 2015 Came across this thread today when looking for a solution to this issue. This has been happening to me occasionally. I have not found a solution yet. I am not looking for a 'Remove from Project' menu item but rather a 'Remove from Library' option when trying to get rid of a method I no longer need. The offending method cannot be dragged out of the class. If I delete it, the class complains and I cannot remove the reference to it still. The only solution I have found is to hack the .lvlcass XML and manually remove any reference to the method. This definitely needs a CAR. I am seeing this in LV2015 so it is still broken. I can confirm I have also seen this behaviour recently with LV2015. Manually editing the .lvclass was the only thing that worked for me. Quote Link to comment
MikaelH Posted November 13, 2015 Report Share Posted November 13, 2015 It's easy, there is probably a vi with that name in memory, so if you would remove the class prefix there would be a conflict. Rename the vi first to something unique and the try to delete it. 2 Quote Link to comment
John Lokanis Posted November 13, 2015 Report Share Posted November 13, 2015 That works! What a weird behavior. I think the reason I only see this rarely is because almost all of my code is in a class namespace. In the most recent case, I made a new VI outside of a class to do the same function as the original method because I wanted to use the function in multiple classes. FWIW, the VI does not have to be 'in memory' necessarily. Just has to be in the project. Quote Link to comment
MartinPeeker Posted November 25, 2015 Report Share Posted November 25, 2015 I just had the same problem. Couldn't create override methods using GDS. Couldn't remove file from project. Rename and remove worked, but still couldn't add override method with GDS. Adding it the override using LVOOP worked, but again, couldn't remove it from project. Turns out I had vi:s with the same name in dependencies. They were there since I had used the GDS clone method to another class for a number of vi:s, the removed them from the original class. This included a polymorphic vi that referenced these, only the references weren't transfered so they now pointed at the vi:s with the same names under dependencies (these were the files previously removed from the original class after the clone). Somewhat confusing, but thought I'd share anyway... Quote Link to comment
Lim Teik Yee Posted March 3, 2017 Report Share Posted March 3, 2017 hello guys, i encountered similar problem and can reproduce the problem the problem is when you have two object (control or vi), one belong to a class and one belong to nothing the one belong to the class cannot be removed because the memory is occupied by the one belong to nothing Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.