>Ed, thank you for reply.
>
>I have a lot of reports with different data. It is impossible to make them
>error free. So errors occurs sometimes and cause my web application to
>spot responding since modal error is displayed in screen.
>
>I tried to use
>SYS(2335,0)
>
>but this does not work from .EXE .
>
>How to fix this VFP bug ?

I don't know, since I don't have the problem. The workaround for the Outlook dialog is not applicable to your situation, since (1) you don't know if the dialog is going to fire, (2) you can't predict the time it will fire, and (3) you can't differentiate the Window using AppActivate(). I'd guess that a monitor of some sort in the Windows event loop that responded to the creation of the messagebox might be an answer, but it isn't really suited to use in a COM environment IAC, and wouldn't be coded in VFP or a small script either. Perhaps you should reconsider your choice of report generation tool; there are times when the native tools don't give you the needed control, and this sounds like one of them.

Without knowing what errors you are encountering that cause your problems, I can't say if it's a bug or not; modal error dialogs can be a normal behavior of both Windows GDI and the VFP Report Writer, since they are intended as interactive behaviors by design. You might consider a proactive approach that detects and prevents the errors rather than trying to shoehorn in a behavior that is not intended; from what I see, it's like complaining that the Windows OS intercepts memory exceptions and shuts down VFP before the VFP error handler can take any action....


>
>>>I use VFP REPORT command to create reports in Web server.
>>>However, if there is an error in report, VFP displays
>>>modal centered error messagebox having OK and HELP buttons.
>>>This box which cannot be captured by ON ERROR.
>>>
>>>Is it possible to use your code to Click the OK button in this messagebox ?
>>
>>I doubt it will work in that situation, but you could always try it. The problem comes with knowing the exact text in the Window title (an inexact name can be used, but the results are unpredictable, since the first Window encountered matching as well as another window will be taken as the app window by AppActivate(). In addition, the timing of the delay needs to be predictable; firing AppActivate() and SendKeys() too early may cause the app to eat the keystroke.