"Just in time" debugger

I have a couple of ActionStudio actions which call a DOS program. They work, but if the DOS call fails, they tend to pop up a "Visual Studio Just-in-Time Debugger" window, asking if I want to debug.

 

"An unhandled Exception ('Object expected') occurred in Finalbuilder5.exe [3060]." ... "Do you want to debug using the selected debugger?"

 

Is there anything I can do about this? The problem is that once it comes up, my build basically pauses indefinitely...even setting a timeout on that action doesn't work.

(Yes, I have Visual Studio 2005, and .NET 2003 installed, and I need them installed to carry out the build...)

Steve

Hi Steve,

See here:

http://msdn2.microsoft.com/en-us/library/k8kf6y2a(vs.80).aspx

Regards,

Angus

Thanks Angus! I tried that (disabling it in all 3 VS products). Now, sadly, I get this message:

An unhandled exception (“Object expected”) occurred in Finalbuilder.exe Just-in-time debugging this exception failed with the following error: No install debugger has JIT debugging enabled.

:frowning:

I guess the best workaround for me is not to use an actionstudio action, but to just use a pure “execute program” step.

Steve

Hi Steve,

Oh, I didn't realise that the error was coming from your script (sometimes programs totally unrelated to FB can bring up this dialog.)

If you debug using the selected debugger, can you see what line is causing the error? It's possible some of the boilerplate code which ActionStudio injects is not working well if the program fails.


If the script error is coming from your script code, then you can do one of three things:

1) Disable script debugging under Options -> FinalBuilder -> Scripting.

2) Put some error handling around whatever line is failing

3) Test for nil/Nothing before the line which fails.

Ah ha! I should have been clearer.

1) Works perfectly. Thank you :slight_smile:

2) I’m really not too fussed about trying to fail gracefully - if the program fails, it fails. Here’s the line that’s failing fwiw though:

function OnFailure(Context, iRes) {
//Parameters : Context - Provides access to the properties
// iRes - The return code from the exe.

Context.SendLogMessage ("Action Failed with Return Code : " + CStr(iRes));
return false;
}

(Presumably Context is null at the time this is called, causing the “Object expected” error?)

Steve

Hi Steve,

That sounds like a bug. If you get a chance, can you confirm that Context is null (using the debugger.)

Thanks.

- Angus

Hmm, I don’t really know how.

That line is highlighted in yellow.
Hovering over “Context” lets me expand it out and see for example that Properties.Count is 2
Context.SendLogMessage is “undefined”
iRes is 2

Adding a watch for “Context==null” is false.
Adding a watch for “!!Context” is true.

Heh, I’m such a hack. I should do more coding.

I tried adding a check for undefined or null, but apparently Context wasn’t either of those. And when I replaced the whole method with a simple “return false;” FinalBuilder just hung (not responding).

Steve

Thanks for your help Steve. What version of FB are you using, I’ll see if I can reproduce this.

5.5.0.412.

Also, I’m not sure if I made this clear, but this is the OnFailure method.

Seems no matter what I add as the text, I either get the Just in time Debugger, or FB hangs. If I make it “return true;”, the action is displayed as having complete successfully…then it hangs.

Wait. Ah, actually now it looks like I may have been confusing the issue. At the time I was doing this test, I had an instance of fbcmd.exe running the same project, but with the /s option. Once I killed that off, it stopped hanging.

Ok, now I’m getting something more consistent: doing a simple “return false;” works fine. But any reference to Context (even if it’s “if (Context == undefined)”) triggers the JIT debugger. Referring to iRes is fine. And referring to some other nonexistent variable gives a different error message: foo is undefined.

Steve

Hi Steve,

Must be something more complex than just OnFailure, because my test project is working fine.

Could you please send the .fbap file to support so we can take a look at it?

Thanks.

- Angus

Done.

Resolved via email (there was a VBScript construct - CStr - left in the OnFailure event from when the action was refactored from JScript to VBScript.)

Dammit, that’s really sloppy debugging/investigation on my part. Thanks, though.

Steve

No problems. It’s strange that the JScript parser didn’t highlight the CStr() call as the problem (it would have been trying to resolve it as a function, and failing when no function could be found.)