$04 Suppressing OK message

Ben Price ben at clintelsystems.com
Fri Jun 17 03:30:11 EDT 2016

Hi Kelly,

I am trying to suppress all the window based OK messages that alert 
users to setup / data errors that users see alerting them why a window 
would not open but my automated task just needs to  ignore the message 
and continue processing

I tried to substitute load event handler instead of load error handler 
but with no success.


Load event handler genericCode/suppressOk
OK message Here (Icon) {test}
Unload event handler genericCode/suppressOk

genericCode/suppressOk  - being a code class with function suppressOk

and suppressOk - containing

Process event and continue (Discard event)
; Tying to find the id of the ok event, but could not get it to work.

On 17/06/2016 15:48, Kelly Burgess wrote:
> 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
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com

All the best,

Ben Price
Software Engineer
p: (08) 8203 0550

More information about the omnisdev-en mailing list