| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| Clipper application is launched via a desktop shortcut that calls a batch file which launches the application. If the program bombs out for some reason, the XP command window closes and the user is returned to the desktop. When *I* work with the application I also have a desktop shortcut that calls a batch file but the last line in my batch file is "CMD" which leaves the command window open. I then launch the application by entering the name of the executable. If the program bombs, I am able to see the error messages issued. I don't want the user to have to close a command window every time they exit the application, but I also want them to be able to see any error messages issued. Is there a way to do this? |
|
#2
| |||
| |||
| Dear Scott Coffey: On Aug 28, 1:42*pm, Scott Coffey <n...@noemail.com> wrote: > Clipper application is launched via a desktop > shortcut that calls a batch file which > launches the application. *If the program bombs > out for some reason, the XP command window > closes and the user is returned to the desktop. Is errorlevel set? > When *I* work with the application I also > have a desktop shortcut that calls a batch > file but the last line in my batch file is > "CMD" which leaves the command window open. >*I then launch the application by entering > the name of the executable. *If the program > bombs, I am able to see the error messages > issued. > > I don't want the user to have to close a > command window every time they exit the > application, but I also want them to be > able to see any error messages issued. >*Is there a way to do this? If the progam sets an exit errorlevel, after the executable in the batch file, add this line: IF ERRORLEVEL 1 PAUSE The execution of the batch file will pause until the "Any" key is pressed. ;>) David A. Smith |
|
#3
| |||
| |||
| Scott > I don't want the user to have to close a command window every time > they exit the application, but I also want them to be able to see any > error messages issued. That's what they'll need do. > Is there a way to do this? Clear the shortcut property 'Close on Exit' on the Program tab - they'll need to close the DOS window with the 'x' or by typing 'exit' There's no need to hardcode this - just have them chnage it when they have a problem. The better alternative is to put an error handler in the app. - see the one in Grumpfish (The OASIS), dumps to file/printer your choice. CYA Steve |
|
#4
| |||
| |||
| On Aug 29, 6:42 am, Scott Coffey <n...@noemail.com> wrote: > Clipper application is launched via a desktop shortcut that calls a > batch file which launches the application. If the program bombs out > for some reason, the XP command window closes and the user is returned > to the desktop. > > When *I* work with the application I also have a desktop shortcut that > calls a batch file but the last line in my batch file is "CMD" which > leaves the command window open. I then launch the application by > entering the name of the executable. If the program bombs, I am able > to see the error messages issued. > > I don't want the user to have to close a command window every time > they exit the application, but I also want them to be able to see any > error messages issued. Is there a way to do this? Hi Scott An approach which complements those already suggested would be to append console output to a text file, eg. APPNAME.EXE >> applog.txt While your app's errorhandler might trap the usual runtime errors, internal errors and GPFs usually bomb right out to DOS. Not that it's ever happened to me. Ha ha. Their output (I recall from memory) can be redirected at the command line as in the above example. Richard |
|
#5
| |||
| |||
| "dlzc" <dlzc1@cox.net> je napisao u poruci interesnoj grupi:8d4e5ffd-f2c7-45ba-91e6-266b5e35f71d@p31g2000prf.googlegroups.com... Dear Scott Coffey: > On Aug 28, 1:42 pm, Scott Coffey <n...@noemail.com> wrote: >> Clipper application is launched via a desktop >> shortcut that calls a batch file which >> launches the application. If the program bombs >> out for some reason, the XP command window >> closes and the user is returned to the desktop. >> able to see any error messages issued. >> Is there a way to do this? > If the progam sets an exit errorlevel, after the executable in the > batch file, add this line: > IF ERRORLEVEL 1 PAUSE > David A. Smith what about this idea: .. shortcut to be set to no-exit .. shortcut calls batch file [which calls app] .. on normal termination, app sets errorlevel=99 .. after app there is a test: if errorlevel 99 exit the key is that on unrecoverable err even the error handler may be broken with gpf or something. so, unless intentionaly closed the dos win on normal app termination, leave the dos win opened to show the error |
|
#6
| |||
| |||
| On Thu, 28 Aug 2008 16:42:10 -0400, Scott Coffey <none@noemail.com> wrote: Thanks for the responses guys. Between all your responses I should be able to implement a workable solution. |
|
#7
| |||
| |||
| On Thu, 28 Aug 2008 16:42:10 -0400, Scott Coffey wrote: The other possibility is to edit errorsys.prg to write all error codes to a log file. The code has to be robust and not throw any errors itself. I've had some success with modifying errorsys in the past, in my case reordering the order in which elements are stored in the error alert. Kind regards, Bruce -- Bruce M. Axtens Software Engineer The Protium Project http://www.protiumblue.com http://codeaholic.blogspot.com -- Posted on news://freenews.netfront.net - Complaints to news@netfront.net -- |
|
#8
| |||
| |||
| On Fri, 5 Sep 2008 18:39:52 +0800, "Bruce M. Axtens" <bruce.axtens@gmail.com> wrote: >On Thu, 28 Aug 2008 16:42:10 -0400, Scott Coffey wrote: > >The other possibility is to edit errorsys.prg to write all error codes to a >log file. The code has to be robust and not throw any errors itself. I've >had some success with modifying errorsys in the past, in my case reordering >the order in which elements are stored in the error alert. > >Kind regards, >Bruce Thanks Bruce. |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.