12-12-2013 02:46 PM
Has anyone else had this problem? I have a class VI that has a broken arrow because: "Only VIs owned by a LabVIEW class may use dynamic terminals in the connector pane." But this VI is, in fact, a member of a class (see screen shot below).
This happened shortly after I removed a method VI from the class. Before I did that, there were no broken arrows for any of these methods.
Solved! Go to Solution.
12-13-2013 09:18 AM
Greg,
What version of LabVIEW are you using? Also, have you tried removing and adding the VI back into the class? I have included some links below that might help, however you may have already seen them.
See "Creating a Member VI from the Dynamic Dispatch Template":
http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/creating_mem_vis/
Adding Items to a LabVIEW Class:
http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/adding_items_class/
12-13-2013 09:34 AM
Why did you remove method VIs from the class?
12-13-2013 10:49 AM
Robert & TailOfGon, thanks for the replies. I'm using LV2013. I removed the method from the parent class because that method's functionality was superseded by a different VI I had in mind. It worked, but not the way I wanted. Trying to be efficient, I removed that VI from the library so it didn['t clutter things up.
My best guess is that somehow the parent class became corrupted. I fixed it, but it took a couple hours of work this morning:
The end result of this morning's effort was that, without changing a single piece of code, I'm back to everything running fine. As I said, my only guess is something, somehow, became corrupted. But just removing a subVI from a class shouldn't have caused this headache in the first place....
11-28-2018 11:09 PM
No need of 2 hours, of work:
Just remove the particular VI/VI's from the class that you have assigned and rejoin that again into the class this should solve the need.
Regards,
Priya
11-29-2018 04:53 AM - edited 11-29-2018 04:54 AM
Glad you got it fixed at least.
LabVIEW has a nasty habit of not saving changes to class definitions when closing the software. It may prompt to save many files in the exit dialog, but often enough, the class defintions (including class member lists) is not part of that.
This can lead to a disconnect between VIs thinking they are (or are not) part of a class and the class thinking the opposite.
As mentioned elsewhere, just removing the VI from the class and re-adding it most often solves the problem.
BTW: I'm not sure but I think even using "Save All" doesn't neccessarily save certain changes to class definitions (member lists etc).