S
slacroixak
Guest
Many thanks for your prompt replies indeed Laura Sorry if my last post was a bit too long (it woudl not be here if the topic was mickey mouse). I am am using the same trick as you suggest, which will wrongly assume a 293 stop occurred if a stop occurs for another reason (like Ctrl-Break pressed) in bar.p (if that bar.p does exists). So as I said, I would have to turn this haveStop to a NEW GLOBAL SHARED VAR (of my preferred class static member way) and write NO in it in the very first line of every single .p file launched with a RUN VALUE (such as foobar)... but wait... what if some .p's are sometimes launched with a RUN VALUE() and sometimes launched with a simple RUN bar.p? oh Gee... => another good reason to stress the need of stopping those stops for err293, and make it simply catchable At last, about your last paragraph that is the very key problem (again sorry if I was not clear enough in that thread): the all problem is not *me* as an end-user, but our numerous regular *Joe* end-users. When an error message comes with a red star comes, then he does not do not even read it, throws an expletive and immediately clicks OK, so the offending missing file name is gone to the paradise of bytes. This is why I would be so keen in finding a magic way to retrieve that last untrap-able displayed error message (if only it could be pushed to the ERROR-STATUS system handle, and not only _msg()) Needless to say that redirecting the standard output to a file is not an option because some of these .p's handle some UI or some other OUTPUT TO, plus closing the default stream in case of stop might be a problem. At last, we have multiple hundreds occurrences of RUN VALUE in that app, with variable signatures (not easy to wrap...). That's why I like to catch those with a ON STOP UNDO, RETRY construct in my top main block. So I suppose there is no other magic construct like _msg() to trap the full last error messages.
Continue reading...
Continue reading...