cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Dynamic Terminals only for a VI that is in a class, but the VI already is

Solved!
Go to solution
Highlighted

Dynamic Terminals only for a VI that is in a class, but the VI already is

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.

 

 

Dynamic dispatch error.JPG

-------------------
Greg
Certifed LabVIEW Developer
The Savvy Test Engineer
0 Kudos
Message 1 of 4
(566 Views)

Re: Dynamic Terminals only for a VI that is in a class, but the VI already is

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/

Robert B
RF Product Support Engineer
National Instruments
0 Kudos
Message 2 of 4
(526 Views)

Re: Dynamic Terminals only for a VI that is in a class, but the VI already is

Why did you remove method VIs from the class?

TailOfGon
Certified LabVIEW Architect 2013
0 Kudos
Message 3 of 4
(517 Views)
Solution
Accepted by topic author RGreg
08-27-2015 04:09 PM

Re: Dynamic Terminals only for a VI that is in a class, but the VI already is

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:

 

  1. I closed everything down, exited  LV, restarted it.  I still had broken arrows.  
  2. So I removed all the parent class methods that use dynamic dispatching, taking care to first copy their functionality onto a temporary VI.  
  3. I renamed all the child class VIs and removed any references to parent methods.  No broken arrows.  
  4. I saved everything, closed it down, and opened it back up.  Still no broken arrows.
  5. At this point I had to re-create all those parent method VIs that I override in the child classes.  This is where my actions from #2 came in handy, since I was able to just copy and paste all that code back into the parent class method VIs.
  6. Going back to those child class VIs in #3, I renamed the VIs back to their duplicate names so that they overrode the parent method VIs.  
  7. Still working with the VIs in #6, I added back in any "Call Parent Method" VIs that I had to use.

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....

 

-------------------
Greg
Certifed LabVIEW Developer
The Savvy Test Engineer
0 Kudos
Message 4 of 4
(509 Views)