LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Working around broken child/sibling classes

I need some suggestions for working around broken classes in my class hierarchy.  Here is my situation:

 

I have an application which makes use of "plug-ins" to implement the program's functions.  Each plug-in is a member of a common parent class called "Step.lvclass", and has various methods which implement each step's functions.  The main program, the base Step class, and all of Step's child classes are members of the same project.

 

Unfortunately, I've found that if any of Step's child classes are broken, it breaks the Step class ("One or more of the set of VIs which this dynamic dispatch subVI or property item may call are broken.") and all of Step's child classes ("The parent of this LabVIEW class is broken").

 

Since each of Step's children are dynamically loaded in the application, this isn't a huge problem for the application.  If the user attempts to load a broken plug-in class, they simply get an error message and the plug-in doesn't load.  However, for development, this is a huge problem as I can't run any of the member VI's of any of Step's subclasses as the classes are broken.

 

Any throughts on how to work around this issue?  Is there anyway to temporarily unload or ignore a broken class?  The best solution I've found so far is to remove the broken class from the project, save & close the project (otherwise it is still in "Items in Memory"), the reopen the project.

0 Kudos
Message 1 of 4
(2,578 Views)

Is this the same issue?

=====================
LabVIEW 2012


Message 2 of 4
(2,574 Views)

Yep, it appears to be the same issue.  I too had assumed it was the intended behavior, rather than the undesireable-but-currently-unavoidable behavior described in the thread Steve posted.  As Aristos Queue posted in that thread, this issue is highly annoying for the users who run into it.

 

So has anybody out there found a good work around for this issue?  Something to make the a project more usable when one-of-many sibling classes is broken.

 

Mark Moss

Electrical Validation Engineer

GHSP

0 Kudos
Message 3 of 4
(2,547 Views)

Hi MarkMoss,

 

Unfortunately, this CAR (215296) is still open, and will be fixed on a further release. And sadly I haven't been able to find any work around.

 

Please let me know if there is anything else I can clarify

 

Kind Regards

 

Carlos O

Applications Engineer

National Instruments

0 Kudos
Message 4 of 4
(2,518 Views)