$04 Suppressing OK message

[Kelly Burgess]

Hi Ben,

>Is there any way in Omnis 4 to be able to suppress OK messages so automated process to operate without user intervention?

I assume you mean runtime error messages that are produced by Omnis.  Here's an example of suppressing error messages at Print time, and your automated process would slot in where the print code is:

  Load error handler genericCode/trapPrintErrors     ;; guard against driver problems producing runtime error messages
  Send to printer
  Print report {rTrackBloodPressure (ivRecList,pPrintDate,pPrintIndividual,pPrintTracking,pPrintGraph,pUseOpenGraph)}
  Unload error handler genericCode/trapPrintErrors


That error handler method is in a Code class.

trapPrintErrors
  ;  
  ;  error handler used by $printXXX methods in various objects     ;; prevents cascading runtime error messages when driver problems arise
  Calculate errCode as #ERRCODE
  Calculate errString as #ERRTEXT
  If (errCode<>25207)&(errCode<>25216)     ;; ignore notation errors
    Do $ctask.$okMsg(con('Internal Printing Error',chr(13,13),'There is a problem communicating with your printer.  Error ',errCode,' - "',errString,'"'),'OK',kTrue)
  End If
  SEA continue execution

That method is singling out two error codes and completely suppressing messages in those cases.  For other error codes, it runs an OK message, but a custom one that's not blocking like the built-in messages, and one whose descriptive language we can control.

Your error handler  can be as simple as that (mandatory) last line, SEA continue execution.  Without that instruction the process stops.

** I just saw your second posting.  Knowing the above will still be useful.  Writing your own OK/Yes/No message window would also be helpful, since if you had that, you could simply suppress its opening with a task boolean when you needed to, without touching the calling code all over your library. The other advantage (besides not blocking timers and event handlers) is being able to position it wherever the user is working, where the built-in message will center itself on screen, sometimes too far away from your current top window and the user's focus.

Kelly