shared libraries, dll, on error return to caller and skip rest of vi

[mits]

I am trying to Build Shared libraries (DLL) using labview which will be called by my application. Is there way to stop the executing VI and return value of arguments to caller if for example error occurs in middle of code, without executing rest of the VI? I try using Application Control's >> Stop, and Exit button. But it didn't work. With Stop, it stops the VI in runtime engines but it does not return the arguments. And with Quit, it quits the application, and c++ complains the DLL quits unexpectedly without passing in require arguments.
Is there a way of skipping to the end of executing if error occurs?


Any idea or suggestion?
Thanks
Mitesh

[srm@viewpointusa.com]

The only way I know of is to code your vi that way. It is very common to use the error cluster in this way. the first vi in the error cluster to assert an error would be propogated down the line of sub-vis or functions that also inspect the incoming error cluster. if an error has been asserted, the sub-vi or function takes no action. The exception to this logic is cleanup code that might take an action even if an error has been asserted.
Stu

[mits]

Thanks Stu for your quick reply.
But all the function that outputs an error for are are "Call Library Function Node" and not an error cluster. And we have about 80 of them. Unfortunetly, we didn't program them to take in any error code and execute only when there is no error.
I guess there no way to skip around in labview to execute things. Such as move to the last part of execution in clean up section if there is error.
Thanks.
Mitesh

[srm@viewpointusa.com]

without error clusters, the only other way would be to implement a state machine that exited early on an intermediate error. this sounds like more work than adding error flow to the 80 functions.
Stu

[Greg_McKaskle2]

> without error clusters, the only other way would be to implement a
> state machine that exited early on an intermediate error. this sounds
> like more work than adding error flow to the 80 functions.


I agree, though if you intend to reuse any of these 80 functions
anywhere else in LV, it would be worthwhile to build VI wrappers for
these, and then you can put the error test and skip in the wrapper
diagram rather than in the C code. Then whenever you need to use the
DLL function in LV it has built-in error checking, perhaps an icon, a
description, etc. If you build a simple template with the error
handling, then copy the current DLL nodes into clones of the template,
this shouldn't take that long, probably about the same
as changing the C
code.

Greg McKaskle