LVOOP Recursion crashing labview

[Jon Kokott]

Labview is endlessly crashing on me.

I have some recursive LVOOP classes which i've identified as the origin of the problem.

Essentially I disconnected one of the recursive classes from the hierarchy and now any VI's which used that recursive property are broken and will not allow me to fix the problems without crashing labview. (I can reconnect the hierarchy, but it seems do nothing for me.)

I cannot remove the recursive call as it thinks its VI name is "" and it simply won't "delete" (click on a VI block on the diagram, press "delete" key, and its still there. Do that enough times and it will tell you it cant find the VI, followed by labview crash.)

Is there any way to load a VI without labview trying to load its subvi dependencies? I think this would allow me to atleast remove the problematic calls.

~Jon

[jdunham]

Labview is endlessly crashing on me.

...

Is there any way to load a VI without labview trying to load its subvi dependencies? I think this would allow me to atleast remove the problematic calls.

Can you drop a diagram disable structure around the subvi call you are trying to delete? Can you drop a case structure around it, and then delete the whole case structure.

If you want load a VI without its dependencies, you could try moving it to some other folder on your hard drive, and load it alone. It will give you lots of warnings and searches, but you may be able to get the diagram open and delete the unfound subvis. Then you could move it back and cross your fingers and it might load.

If none of that works, you can probably send your VIs to NI, and ask them to recover the damaged VI.

Jason

[Jon Kokott]

Can you drop a diagram disable structure around the subvi call you are trying to delete? Can you drop a case structure around it, and then delete the whole case structure.

If you want load a VI without its dependencies, you could try moving it to some other folder on your hard drive, and load it alone. It will give you lots of warnings and searches, but you may be able to get the diagram open and delete the unfound subvis. Then you could move it back and cross your fingers and it might load.

If none of that works, you can probably send your VIs to NI, and ask them to recover the damaged VI.

Jason

The diagram disable looked promising, and it did allow me to remove the VI, but unfortunately labview just delay the crash until I try to save the VI.

As far as moving the depenency to a different location, I've tried that, and it makes no difference. Unfortunately the VI i'm trying to delete isn't being found by labview anyway, so moving a VI that labview doesn't think exists doesn't do anything.

mass compiling doesn't help, and I'm starting to think that the recursion in LVOOP isn't ready for primetime in LV8.6.

~Jon

The diagram disable looked promising, and it did allow me to remove the VI, but unfortunately labview just delay the crash until I try to save the VI.

As far as moving the depenency to a different location, I've tried that, and it makes no difference. Unfortunately the VI i'm trying to delete isn't being found by labview anyway, so moving a VI that labview doesn't think exists doesn't do anything.

mass compiling doesn't help, and I'm starting to think that the recursion in LVOOP isn't ready for primetime in LV8.6.

~Jon

Eventually working with that diagram disable structure allowed me to remove the bad VI in question. I had to throw the diagram disable structure over the bad VI, then delete it using a replace with vi. The VI I replaced it with had to be an express VI (I think the fact that express VI's enforce some kind of special recompile had something to do with it.)

thanks for the diagram disable idea,

~Jon