Coercion dots using classes in conditional structure

[mbechtold]

I am trying to create a plugin driver that is LVOOP based.  We have certain drivers we do not want to release.  Therefore I am attempting to use conditional disable diagram to select which class is available.  One of my questions is why do I get coercion dot between these conditional disable cases?  If these are part of a project packed library, does the disabled conditional code included as a dependancy?

In the below example the release case the base class is used and in the development case the derived class is used.

 

[mikeporter]

If the code is working I wouldn't get too concerned about the issue. There are a lot of situations where LV shows extraneous, transient or incorrect coercion dots. You can try and report it to NI but unless it breaks the code, they tend to view these things as a "purely cosmetic issue".

Mike...

[mbechtold]

What brought me to looking at the coercion dots was once they are visible, building a packed library LabVIEW fails to initialize the builder.  This issue is not remedied until the offending class is removed from the project and the project is closed releasing the class from memory.  If I move the conditional disable out side the case statement there are no coercion dots.   Also switching between conditionals disable cases does not change this coercion.  When I go to build the packed library LabVIEW still locks up.

In summary I believe that the build locks up when ever switching between conditional disable cases.

[mbechtold]

I'm sorry  I don't my building a packed library issue is related to the conditional disable and the coercion dots.  I am going to start another thread regarding the LabVIEW locking up when building a packed library.

Thanks