Error Dialog

[erezpaz]

Hi

Is there  a way to control the basic error dialog WIL create when there is an error?
I am not referring to ErrorMode(@OFF) to remove minor errors. I am referring to controlling what the error look like and present.
For example it show my source working directory even though i am running on deferent machine. Also change the error icon or change the size and more.

Thanks
Erez

[td]

There is no way to 'control' the content of the basic WinBatch error message dialog.  Your only alternative is to turn it off completely and create your own error dialog.  See IntControl 73 and Dialog function in the Consolidated WIL Help file for more information.

[stanl]

Or, check the Tech Database for "errorhandler" - many of the scripts that are returned have an errorhandler() udf that may help.

[snowsnowsnow]

I actually think the best way to attack what I think is the real underlying issue here is to run in "Quiet Mode", with an errorlog file.  Look up IC(38) for the details.  When you run in Quiet Mode, when your script hits an error, it will just quietly exit (writing all the details that are usually displayed onscreen into the error box to a file).  Then you can retrieve that file and find out what happened.

That said, what follows is editorial:

I know that many posters to this board think that WinBatch dialogs are just the cat's meow, but I try to avoid them if possible.  I generally find that if I am considering using a dialog, that I'm working too hard.  Almost always, there is a built-in way, possibly with some small tweaking, that comes close enough to what I want for me to be satisfied with it.  And it is a lot easier than writing the dialog code.

[td]

The OP's post seems to imply that he wished to continue displaying errors and not just suppressing them.   Intcontrol 38 is not the best way to do that but perhaps, as I think you are implying,  suppressing errors would serve OP's underlying purposes better.

WIL Dialog Editor and WinBatch Studio generate almost all of the 'dialog code' for you.  For many purposes you just need to uncomment a couple lines and plug in the code you would be writing anyway.   However, like anything else WIL dialog code can get more involved when more sophisticated relationships need to be expressed.

[snowsnowsnow]

The OP's post seems to imply that he wished to continue displaying errors and not just suppressing them.   Intcontrol 38 is not the best way to do that but perhaps, as I think you are implying,  suppressing errors would serve OP's underlying purposes better.

First, bit of terminology here:  IC38 does not "suppress" errors, in the sense that, say, ErrorMode @OFF does.  Therefore, what I am inferring from OP's post is that his real goal is to prevent the user from seeing stuff (presumably, stuff he doesn't want user from seeing, such as the name of his source code directory - which, as he says, is on a different machine, so is not relevant in the user's context anyway), but that he still wants the script to abort (as it does when an unhandled error occurs).

And, as a bonus, the developer (that is, the OP) can check the file after the fact (*) and see what went wrong.  The whole point here is that an error box does nothing for the (typical) unsophisticated user - and just basically annoys them.  That's why IC(38) *IS* the right solution.

(*) In my systems, I had mechanism in place to automatically email the IC38 logfile back to me whenever one was created in the field (running remotely).

WIL Dialog Editor and WinBatch Studio generate almost all of the 'dialog code' for you.  For many purposes you just need to uncomment a couple lines and plug in the code you would be writing anyway.   However, like anything else WIL dialog code can get more involved when more sophisticated relationships need to be expressed.

I, of course, understand all that - although, TBH, I was never really able to get the Dialog Editor to work the way I think it ought to work - that is, like any code generation system, once you start human-editing the output of the code generator, you can't ever use the machine (in this case, the Dialog Editor) again.  It's a "You can't put the toothpaste back in the tube" situation.

But this is all just my personal opinions and experience.  I still stand by what I said that, most of the time, if you are thinking about using dialogs, you're working too hard.  Which underscores all too well one of the fundamental problems with the current workplace ethic - which is that the harder you are working, the better.  I, being the lazy sort I am, think just the opposite is the case, and I always did what I could to make it possible for me to work less hard.

[td]

First, bit of terminology here:  IC38 does not "suppress" errors, in the sense that, say, ErrorMode @OFF does.  Therefore, what I am inferring from OP's post is that his real goal is to prevent the user from seeing stuff (presumably, stuff he doesn't want user from seeing, such as the name of his source code directory - which, as he says, is on a different machine, so is not relevant in the user's context anyway), but that he still wants the script to abort (as it does when an unhandled error occurs).

Yes, you are correct.  IntControl 38 terminates execution as well as suppress the error message box.  ErrorMode @On does not terminate on minor errors.  I should have elaborated a bit more and been precise.

And, as a bonus, the developer (that is, the OP) can check the file after the fact (*) and see what went wrong.  The whole point here is that an error box does nothing for the (typical) unsophisticated user - and just basically annoys them.  That's why IC(38) *IS* the right solution.

(*) In my systems, I had mechanism in place to automatically email the IC38 logfile back to me whenever one was created in the field (running remotely).

While it may be the case that the standard WinBatch error message 'does nothing for the (typical) unsophisticated user.',  you need to keep Joe user informed and that is where something like IntControl 73 is very  useful.  IntControl 73 allows you to do everything you claim for IntControl 38 plus offers many additional error handling options.  The need for those options my not be apparent in your environment but there are environments where they are absolutely necessary.

I, of course, understand all that - although, TBH, I was never really able to get the Dialog Editor to work the way I think it ought to work - that is, like any code generation system, once you start human-editing the output of the code generator, you can't ever use the machine (in this case, the Dialog Editor) again.  It's a "You can't put the toothpaste back in the tube" situation.

There is nothing stopping you from loading a hand edited template back into the Dialog Editor unless it contains errors (the editor is tolerant of some kinds of errors) or you use substitution in your template.  Of course, you are using an old version so things have changed a bit.

But this is all just my personal opinions and experience.  I still stand by what I said that, most of the time, if you are thinking about using dialogs, you're working too hard.  Which underscores all too well one of the fundamental problems with the current workplace ethic - which is that the harder you are working, the better.  I, being the lazy sort I am, think just the opposite is the case, and I always did what I could to make it possible for me to work less hard.

Can't say that I have ever encountered a workplace that has the 'the harder you are working, the better' ethic as you describe it although I am sure it exists.  For the most part, the workplace platitudes I have encountered the most over the years that might imply some kind of ethic usually contain some form of the phrase  'working smarter'.  Perhaps that phrase encompasses what you refer to as 'lazy'.    Of course, in the software industry software developers seem to take a special pleasure in those elegant lines of code that while small in number accomplish a great deal.    I don't spend to much time fussing about the number of lines of code, as writing the lines of code is an almost the enjoyable after thought in the development process.  The one indirect exception comes when performing code analysis which can involve things like predicting the number of bugs that should be detected and corrected per a complexity score.  Complexity and line count don't always go hand-in-hand but obviously, there is a bit of a correlation.

[td]

Noticed this lead paragraph from a story in the local paper today (September 26, 2016):

"ATLANTA ââ,¬â€ Microsoft brought out a high-tech version of ââ,¬Å"work smarter, not harderââ,¬Â on Monday, pitching a slate of next-generation software tools designed to help businesses better use their technology." - written by Mat Day for The Seattle Time.

The full not particularly interesting article is here:

http://www.seattletimes.com/business/microsoft/microsoft-touts-its-smarter-security-tools/