Child class not called at run time labview

[Nitrof]

I'm developing a large application using a few Class.

In development mode, everything works fine.  When I build the application and run the executable, one of my child class is not called at all.  In some of the methods of that child class I have checked the option in "Window Appearance" to show the Front Panel when VI Load.  The VI show it self but is not executing.  The run button is in a state that indicate there is no top vi calling it.

I have played whit Execution : Preallocated clone reentrant execution and General: Separate compiled code from source file.

And I set them back to default.

Two days lost trying to figure what append to my application.

Please Help.

Nitrof

[elset191]

Are you calling your children dynamically, say, using the factory patter?

In your build specifications try adding the children classes to the Always Include section of Source Files.

[Nitrof]

> Are you calling your children dynamically, say, using the factory patter?

The children is using Dynamic Dispatch if it is your question.  I don't know what is a factory patter.

> In your build specifications try adding the children classes to the Always Include section of Source Files.

Yes I tried.  It did not worked.

I have ben able to make it work by adding a "To more specific class", see picture below.  It is as if the dynamic dispatch not working.

 This one forces the use of the child class

This one is as it should be...

[elset191]

In the build specs on the Additional Exclusions page, is Remove Unused Polymorphic Instances checked?  If so, try unchecking it.

[Nitrof]

In Additional Exclusion, Uncheck "Remove unused polymorphic VI instance" did not solve the issue.

[Nitrof]

I just build a VI that show all VIs in memory.  It show every VI path with its running state: (Idle, Running, Run top level).

When I double click on a VI in the list, the panel is open.

Supprise, ther is a broken arrow on the front panel of the Dynamic Dispatch VIs.  The complete class parents and child has a broken arrow.

When I click on the broken arrow I get this message:

"VI has an error of type 2002200.  The full development version of LabVIEW is required to fix the errors"

I realy don't understand, everything was working fine last time I generated an exe whit the application builder.  Now it only works in Development Mode.  I included the total lvlib containing all the classes used in the project.

When I use a : "To more specific class", using a new instance of my child class it works in the exe.  But that way, I loose all the magic of having LOOP, no more dynamic dispatch.

[Nitrof]

This is one situation where I can say LabVIEW sucks. Creating an object-oriented programming and having a different behavior mode of development and implementation. I'm running out of ideas to solve this problem.

I had some of my classes that were contained in a file .LLB. I moved all in a folder instead, fearing that it might have something to do with my classes problem . Now, the VIs are idle rather than broken. I may have improve things, but I still not able to produce a functioning release software.

[Alex+ra]

Hi Nitrof,

Check out this excerpt straight from the NI Training Manual on object-oriented programming (image attached). There's a chance that the child classes aren't being included in the build. They need to be included somewhere in the application VI so that the Application Builder knows to include the class in the build.

Also check out this forum that sounds like it's describing a similar problem: http://forums.ni.com/t5/LabVIEW/Problems-with-dynamic-class-load-in-executable/m-p/2139116

Hope this helps!

Alexandra

[Nitrof]

Thanks for the information, I will take a look.

But, I must mention that it was working before and now it doesn't.  In the exchange with Sourcesafe, we have experience a class mutation problem.  We had to roll back to a previous class version.  Now everything is functioning in dev mode and not in exe.  I fear that the mutation issue cause some sort of corruption in our project.  Now one solution may be to re-develop the classes.  I want to avoid that.

Regards,

Nitrof