TERMINAL WIL ERROR=>9999 (User requested Cancel)

Started by mcvpjd3, July 31, 2017, 08:58:05 AM

Previous topic - Next topic

mcvpjd3

Hi all, I'm hoping someone here will see this and know immediately what's going on, otherwise this may get messy....

I've got a winbatch exe that we use for a login script for all users in our domain which runs fine. We are about to migrate all our users to a new domain and are testing the script in the new domain, and guess what...

So in the source domain is pops up a little window to show you what it's doing, when we run it in the new domain, the window pops up, but then it stops. If I run it with debugtrace at the end I get these lines:

[ Dialog Callback Triggered ]
ButtonPushed=Dialog("MyDialog")
(47) CALLING UDF (mydialogcallbackproc)
RETURNING FROM UDF (mydialogcallbackproc)
[ Dialog Callback Triggered ]
ButtonPushed=Dialog("MyDialog")
(1061) CALLING UDF (mydialogcallbackproc)
RETURNING FROM UDF (mydialogcallbackproc)
ButtonPushed=Dialog("MyDialog")
(1108) STATEMENT SKIPPED

TERMINAL WIL ERROR=>9999 (User requested Cancel)


If I run it in the source domain it works fine and I get this at the end:

[ Dialog Callback Triggered ]
ButtonPushed=Dialog("MyDialog")
(219) CALLING UDF (mydialogcallbackproc)
RETURNING FROM UDF (mydialogcallbackproc)
[ Dialog Callback Triggered ]
ButtonPushed=Dialog("MyDialog")
(1233) CALLING UDF (mydialogcallbackproc)
RETURNING FROM UDF (mydialogcallbackproc)

WIL ERROR SUPPRESSED =>9000

ButtonPushed=Dialog("MyDialog")
(3947) ==>FALSE=> (skipped)
--- Normal termination ---
;;;END OF JOB;;;


The obvious difference is the WIL ERROR SUPPRESSED and TERMINAL WIL ERROR messages, but I'm not sure why I'm getting these? Any ideas?

Thanks

td

9000 is the normal termination.  9999 means that WinBatch received a cancel or close command in it's message loop.  Cancel and close command Windows messages are generally but not always the result of some user interaction with the UI.  For example, user the mouse to press the Cancel button in a message box.  Neither number is an errors and both are part of normal processing.

Without a lot more information it difficult to speculate in a useful way about what is causing the difference in behavior in this case.     
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

cssyphus

For anyone searching in future... I discovered this error after upgrading WinBatch from 2011 to 2018. A script I had written long ago was using 6.1 dialogs, wherein dialog controls are identified by integers. WinBatch 2018 uses the 6.2 dialogs with their very welcome dialog control names, which are text strings.

My original dialog callback procedure was using switch statements to determine which dialog control had been triggered - and the switch statement handles only integers.  By changing from switch statements to if/elseif/endif statements, problem was solved.

Due to the complexity of my script the problem was a bit of bother to solve, so posting this in case it saves someone else the bother. And several clumps of hair.

cssyphus

Two years later... encountered this problem again, but this time it was a different cause/solution.

I was creating a new (and quite complicated) dialog, and had just started building the Dialog Callback Procedure.  I only had a couple of lines in the procedure, setting a couple of variables, just to watch the script go in there, but I had forgotten to return anything! What I observed was that the script would start... and stop immediately. Adding a DebugTrace() command, I saw the script enter the callback procedure, and then end with the same error: TERMINAL WIL ERROR=>9999 (User requested Cancel)

The solution was to return a valid value, in my case -2 (to allow the dialog to remain on screen).

To make my code more readable, I follow Tony's recommended of setting usefully-named variable constants, so my actual return statement was:  return c_DO_NOT_EXIT.  Again, I got same error TERMINAL WIL ERROR=>9999 (User requested Cancel).  I had forgotten to actually create that variable, so I was trying to return a non-existent variable. As soon as I create the variable at the top of the script, everything worked perfectly.

So, those are two more things to check if you encounter this error.