Error 1556 in exe build run

[AristosQueue (NI)]

Ben: Try this please... add the Conditional Disable Structure shown in Actor.vi. After looking at the code with the workaround you described, I could only think of one thing that was exceptional about this subVI. Be sure you add it to only the True case of the Case Structure, not the False case.

[Ben_Phillips]

I'll answer the questions shortly, but wanted to say this first.

I don't know for sure which function it is that returns the error, since it only happens in exe mode.  But when I fixed the error 15 resulting from the missing panels in the build, the 1556 error got squished too and everything ran happy.

This is why I think that happens, with my less than full knowledge of the core AF black magic.  If there's an error coming out of the native Asynch call in Launch Actor, the dequeue operation is going to be skipped and the caller-to-actor enqueuer is going to be bogus.  I don't think it is caused by code in actor core, things are hosed by the time that gets called the first time.

It seems like a minor modification in the way that errors are passed along and merged could fix the main problem I had.  The dequeue operation (blue arrow) should not have an error in passed to it, go ahead and try it even if there was an error on the native asynch start.  Or at least filter out the error 15 from a missing panel before passing that into the dequeue.

IMO, something like missing a panel should result only in the inconvenience of missing that window if you wanted it open, but the actors would still run headless.

And this has more implications than what I can probably conceive of, but launching an asynch process that is missing its panel seems like it's closer to a warning than a straight up error (talking regardless of AF).  Seems like that would make it a lot more obvious what's happening when you have missing panels in a build.  "oh, everything runs as before, but why doesn't my karaoke lyrics panel come up along with all the others?  oh, we got an error 15 but it still seems to work, we must be missing a panel"   (and please keep this a secret, but this karaoke program is going to change the world.)

If I'm right, then back when I had the panels removed in the build, the actors would have been launched headless but there's no valid way to ever reach them since we never got the caller-to-actor queue.  That would seem consistent with the behavior I saw.

[AristosQueue (NI)]

Ben_Phillips wrote:

And this has more implications than what I can probably conceive of, but launching an asynch process that is missing its panel seems like it's closer to a warning than a straight up error (talking regardless of AF). 

I'll review the implications later, but if the panel is the only way to stop the actor then not loading the panel when it was requested is a definite problem. And just starting something running headless gives no feedback whatsoever to the user that something is sorely wrong. So I'll try to fix the panel situation one way or another (make it work or fix the error handling), but in general, I think this has to be an error.

[Ben_Phillips]

Completely overlooked that in many cases the UI would indeed be the only way to stop some actors.  Was thinking biased --> my project, you're right that it needs to be an error.

[AristosQueue (NI)]

Ben_Phillips wrote:

It seems like a minor modification in the way that errors are passed along and merged could fix the main problem I had.  The dequeue operation (blue arrow) should not have an error in passed to it, go ahead and try it even if there was an error on the native asynch start.  Or at least filter out the error 15 from a missing panel before passing that into the dequeue.

To begin with, the error handling as it stands is correct. If the error were not wired, those Dequeue operations would hang indefinitely because the only way any information ever gets enqueued is by running Actor.vi, and an error from the Async Call By Ref indicates that the Actor.vi did not start running.

Second, I think that the fix I proposed for Actor.vi is the correct fix to stop the runtime engine from requiring the panels for every Actor Core.vi. Attached to this post is a modification of Actor.vi saved for LV 2012. Please BACK UP your current Actor.vi and then replace with this one and see if it fixes your problem when you rebuild your EXE. If it does, I will update the official version. Right now it is returning error code 1634 in the runtime engine which is undefined in 2012 but will have a definition in LV 2013 to explain that the "open the panel" option is not supported in the runtime engine (which isn't arguably a breaking change but that terminal was documented every which way to indicate "this is for debugging only". And, while I realize that people can do remote debugging to an EXE, those folks are going to have to instrument their code. Not optimal, but better than requiring all the panels to stick around). But I'm pretty sure that feature is what is leading to the problems when you build your app.

Please let me know if this helps.

[User002]

Not that I disagree that things function properly, but I disagree with AQ's statement that it is "documented every which way".  I suggest that the context help for Launch Actor.vi have a note about it. (I didn't check the detailed help and lost some time figuring out why my application didn't lauch properly.)  Also, why don't we rename the terminal to something like "Debug Show Panel" that would indicate by its name that it's not intended for normal use.  I wouldn't be opposed to removing the terminal entirely, at some point novice users like me are going to have to learn the right way to show the launched .vi's panel.  Might as well make it early.

[AristosQueue (NI)]

fairlyFunctional: You are correct in your criticism. I just re-read the docs. The version that we had originally posted here in the forums had a terminal named "Open panel? FOR DEBUG ONLY" which got modified to match LV style when it became part of LabVIEW. Also, I had just that day been reading through the documentation for LabVIEW 2014. In the new edition, it says this:

The true setting will return an error in the runtime engine. Actors that need to open their Actor Core panels outside of debugging should either use the FrontPanel.Open method or configure the VI Properties to open the panel when called.

It does not say any of that in 2012 and 2013. My apologies.

[Jeannius]

Any plans on fixing this?

Because the exact same behaviour should happen between the VI in a project and the executable that is built upon that VI.

I spent 48 hours pulling my hair before I found this post. This use to not be the case with AF back in 2012 and 2013.