Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Keywords: debugtrace tGetLastError LastError()
adeErrorHandler = IntControl(73,0,0,0,0) (82134) VALUE=> "2" adeEM = ErrorMode(@Off) (82136) VALUE=> 1 adePriority = tGetPriority(autProcId) (82138) VALUE=> 0 EXTENDER ERROR SUPPRESSED =>201 (201: Open Process Failed) ErrorMode(adeEM) (82140) VALUE=> 0 IntControl(73,adeErrorHandler,0,0,0) (82142) VALUE=> "0" if adePriority == 0 (82144) IF DO==>TRUE xyz = tGetLastError() (82145) VALUE=> 87 if xyz == 201 (82148) END OPERATOR
>The attached snippet from a >DebugTrace shows a discrepancy >between the error reported in >the trace and the value >obtained from tGetLastError.tGetLastError is designed to retrieve EXTENDED process error information. Therefore inorder to retrieve the last extender error see the WIL function LastError().
I noticed you are using the ErrorMode and IntControl 73 error suppression options. You might want to chose just one, depending on your needs.
>This is with the 2001 compiler >and the latest Proc extender. >I'm not trying to be anal >about it but it would be nice >if the numbers agreed.They are designed for different uses. Please see the LastError function to capture the error 201.
>In my >application I'm using >tGetPriority to determine when >a process has exited. After >many tests I've discovered >that a 201 (Open Process >Failed) means one thing and a >237 (Unable to Get Priority) >means something different.Yes, they do mean something different. Hence the different error messages.
>Sadly I'm now faced with >redoing a bunch more tests >hoping to discover the magic >value tGetLastError returns on >a 237 condition (which happens >infrequently). My fear is >that I'll run all those tests >only to discover that the >distinction is lost and >tGetLastError returns 87 in >both cases.Here is an example on how to capture the last error and the Extended error.....
;This example is designed for NT ;Addextender("wproc34I.dll") AddExtender("wwprc44i.dll") counter="bad string to force error" typeflag=0 ErrorMode(@off) ret=tGetdata(counter, typeflag) ErrorMode(@cancel) if ret==0 WILerr=LastError() Extendererr=tGetLastError() message("WIL Last error",WILerr) message("Extender Last error",Extendererr) exit endif Message("tGetdata - value of %counter%",ret) exitI will be happy to help you debug. PLease remove all error suppression for debugging, except for error that you truly want to ignore......
WIL ERROR SUPPRESSED =>1233 (RegQueryValue: Function Failed) EXTENDER ERROR SUPPRESSED =>237 (237: Unable to Get Priority.)ErrorMode is off to let the WIL interpreter know that this is an anticipated error. IntControl 73 is off to avoid a jump to my error handler. (The code is just a tiny fragment of a large script where the error handler is useful.) FWIW this reminds me: it seems to me the WIL interpreter should not jump to the error handler anytime ErrorMode is off.
That has been fixed in the latest version. Sorry for the confusion. I agree that bug in DebugTrace, made it very misleading...
Article ID: W14792
File Created: 2013:04:01:09:13:02
Last Updated: 2013:04:01:09:13:02