LVOOP - VIs for Override will not execute if sibling is broken

[hecmar.arreola]

Scenario:  I have a parent class with two children that are independents (Child Class A, and Child Class B).  Child Class A does not reference Child Class B or vice-versa.  In the parent class I have a VI called "Populate Object" that is to be overridden by its children.

Child Class A has an incomplete implementation of "Populate Object" and is therefore broken.

Child Class B has a complete implementation of "Populate Object" and should execute fine.  However, the VI will not execute (Broken arrow button).

Bringing up the Errors and Warnings dialog has the Child Class B: Populate Object.vi in the list.  When I select that .vi, it says "0 errors/warnings".  Ummmm.... Ok...

I go back and fix the errors in Child Class A: Populate Object.vi, and magically the Child Class B: Populate Object.vi will execute.  Is this by design?  This doesn't seem like it would be a useful, if it is by design.

Edit: Uhg.  Spelling.  I wish my web browser's spellchecker worked in this form.... /sigh.

Message Edited by Nickerbocker on 02-18-2010 10:11 AM

[Ben]

Which flavor of LV?

The error messages are gtting better with each new release.

Ben

[hecmar.arreola]

Hi Ben,

Thanks for the reply.  I'm in LV2009 SP1.

Yeah, good error messages help a lot.  I don't know how many times i created this VI for override in this child object and removed it from my project thinking LabVIEW was confused or something...lol.  Spent a good 30 minutes pulling my hair out.  Went to the sibling implimentation of the VI, drew a big disable block over the broken code and all the errors went away.

[Ben]

---

Nickerbocker wrote:

Hi Ben,

Thanks for the reply.  I'm in LV2009 SP1.

Yeah, good error messages help a lot.  I don't know how many times i created this VI for override in this child object and removed it from my project thinking LabVIEW was confused or something...lol.  Spent a good 30 minutes pulling my hair out.  Went to the sibling implimentation of the VI, drew a big disable block over the broken code and all the errors went away.

---

And if you are really a gluton for punishment, IN LV 8.2 try changing the icon connector pattern of one of children and then move it from a Virtual Foder marked private to one marked as public.

It rate right up there with charging a cap using a megaohm meter and tossing it to your "buddy". Its only funny if you are in on the joke* ahead of times.

Ben

Dragging out the analogy out... LVOOP R&D probably had to fix those messages since the non-stop belly laughs (Ha ha silly Ben didn't notice the arrow broke three minuts ago, let's see how long it takes him to figure that one out) were getting to them.

Message Edited by Ben on 02-18-2010 11:42 AM

[hecmar.arreola]

Good luck charging it up w/o it popping in your hand ;).

My favorite part of new-coop initiation: What happens when you exceed the voltage of a capacitor training.

[shew82 · Accepted solution]

I spoke to NI Support about this very same thing a while back because it is very hard to find the actual cause of the error with classes that have large numbers of VIs and/or children - I was getting over 100 error messages all due to a problem in 1 VI!!!

I was told that this was not the first time such a comment had been raised, but as it had still not been solved it was "probably not super quick to fix".

One thing that I did find to make life a little bit easier is to search to the top of the error window and look for red X's -> these indicate the actual VIs that are broken, as opposed to VIs that are broken because they are calling something that is broken, etc.

Shaun

[Ben]

---

shew82 wrote:

I spoke to NI Support about this very same thing a while back because it is very hard to find the actual cause of the error with classes that have large numbers of VIs and/or children - I was getting over 100 error messages all due to a problem in 1 VI!!!

I was told that this was not the first time such a comment had been raised, but as it had still not been solved it was "probably not super quick to fix".

One thing that I did find to make life a little bit easier is to search to the top of the error window and look for red X's -> these indicate the actual VIs that are broken, as opposed to VIs that are broken because they are calling something that is broken, etc.

Shaun

---

Thanks for posting that Shaun!

That is the approach that has worked well for me.

Ben

[hecmar.arreola]

Indeed.  Thanks!

One question still remains though:  is this by design?  And if it is, why?

[hecmar.arreola]

Now that I think about it, it probably has to do with dynamic dispatch.

But wait a second...the Parent's "Populate Object.vi" isn't broken when one of the children VIs that override that method is broken.  Only siblings...  Weird.

[Ben]

Good question that only someone on the VLOOP R&D development team can answer. I'll get teh ball rolling on getting an definative answer. Don't hold your breath because this may take some time.

Logged SR 1489657 to get it started.

Ben

Message Edited by Ben on 02-18-2010 01:15 PM