Very weird behaviour of LV OOP/classes: wrong dynamic dispatch method gets called

[dlanger]

I have very strange problem: a subVI (start_scanning.vi) in my software is supposed to call a dynamic dispatch method (send_trigger.vi) of an LV class:

However, instead of calling the send_trigger.vi method, a completely different method (with a different name and non-matching connector pane) of a parent class gets called. LabVIEW then immediately shows an dialog stating "LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. The top-level VI "main.vi" was stopped at unknown on the block diagram of "GenericPlugin.lvclass:set_current_objective.vi".

GenericPlugin.lvclass:set_current_objective.vi (mentioned in the dialog message) is the method that gets called instead of the correct method. The invalid input parameter to which the dialog message refers to is probably the enum that I pass to my dynamic dispatch method (this enum of course does not match the input parameter expected by set_current_objective.vi). 

I tried to give LabVIEW a further hint that it tries to call the wrong method by putting another input control to the front panel of set_current_objective.vi (and connect it to the connector pane). This indeed changes something: LabVIEW then completely stalls (does not react to ANY user input anymore), but the correct method (send_trigger.vi) is still not executed (probes inside the method do not get executed). The same is the case if, instead of adding an additional control on the front panel of set_current_objective.vi, I try to pass another enum value to send_trigger.vi.

 A further strange observation is that at some point the VI (i.e., start_scanning.vi) trying to call the dynamic dispatch method somehow gets locked (the front panel looks as if the VI were running; and the block diagram cannot be edited anymore).

I would appreciate any hint that could help me solving this problem, as I am really stuck now...

Message Edited by dlanger on 09-11-2009 01:01 PM

Message Edited by dlanger on 09-11-2009 01:02 PM

Message Edited by dlanger on 09-11-2009 01:03 PM

Message Edited by dlanger on 09-11-2009 01:05 PM

[Ben]

First:

That strange look like ti is running is an indication that you have something open running and using that class. This could be a VI running in the background etc. Search this forum for Darrens' Nugget to find and kill background threads.

Q

When you doulble click on the VI you have circled, do you get the dialog box asking you for whcih version to open?

Q

What version of LV?

 Earlier versions of VLOOP could get confused and had a hard time telling us about it. earlier version would also let you set up dynamic dispatch VI wrong and did not properly enforce and enunciate difference in the icon connector.

Beyond that you may have to post of the app so we can poke at it.

Ben

[dlanger]

Thanks for your post, Ben.

When I double-click the dynamic dispatch VI I have circled, a dialog pops asking me to select the version of send_trigger.vi (which is the correct VI).

I use LabVIEW 2009. 

[dlanger]

I am playing around a bit at the moment by adding minor modifications to the code that shouldn't change the program logic (such as putting the naughty dynamic dispatch VI "send_trigger.vi" into a further subVI). LabVIEW than also just stalls. I have attached the failure log file to this post...

Does the following line give use any hint?

"c:\builds\penguin\labview\branches\Orion\dev\source\heapobjs\UDClassDDO.cpp(175) : DWarn: [[VI "DataCollectionDL090215_statechart.lvsc:Diagram.vi:Instance:12" (0x182DE320)]] should not be loading while gLoadingAnyUDClassLib is true.
$Id: //labview/branches/Orion/dev/source/heapobjs/UDClassDDO.cpp#24 $"

Message Edited by dlanger on 09-14-2009 03:05 AM

[dlanger · Accepted solution]

Mass-compiling the whole code seems to have solved the problem.