>>>>Yes, indeed, I have an error in the calling procedure:
>>>>

>>>>TRY
>>>>EXECSCRIPT(EVALUATE(THIS.AliasName + ".reSettings"),THIS.oFormInfo)
>>>>CATCH TO loError
>>>>FINALLY
>>>>ENDTRY
>>>>

>>>>There is an error, and even I don't display the error (it's not crucial), the program writes to the screen. This is awkward. What can I do about this?
>>>
>>>Christian,
>>>
>>>Try in Execscript to add SET TALK OFF + CHR(13) + Chr(10) + the rest of the command. EXECSCRIPT is running in its own environment and the SET TALK may be ON as well as some other settings may be different from your current settings.
>>>
>>>Also why you're not reporting the error? Are you sure evaluate produces a correct string?
>>
>>"SET TALK OFF" inside the execscript does not change the behavior. If EXECSCRIPT runs in its own environment, why would the report preview see settings of that environment? I am not sure what is happening here.
>>
>>The execscript contains a dynamic procedure that is created during closing of the form and contains all value settings on the form. It is a report form class that automatically restores the last user settings. The approach is very generic.
>>The code looks like this:
>>

>>LPARAMETERS toFormInfo
>>toFormInfo.Cntoptionsoutput.cbo.VALUE = [Preview]
>>toFormInfo.ItemsOrUsers.cbo.VALUE = [Report items per user or group]
>>toFormInfo.UserOrGroups.cbo.VALUE = [Users]
>>toFormInfo.SelectGroups.SetRecord(62500938)
>>toFormInfo.SelectUsers.SetRecord(-1)
>>toFormInfo.SelectItems.SetRecord(-1)
>>

>>So it may happen that either the first opening of the screen does not have any code in it, hence the error "Parameter statement not found", or when we remove a control on the form for example, the old settings may not all be valid anymore.
>>
>>So any errors in that procedure are of no concern.
>
>I'm not also sure what's happening, but you may add to your code to make sure to exclude some errors:
>

>SET TALK OFF
>if vartype(toFormInfo) = 'O' and pemstatus(toFormInfo,'baseclass',5) and toFormInfo.Baseclass = 'Form'
>  * proceed
>endif

>
>Does CATCH block execute?

As long as I don't have any errors in the procedure, everything goes well. But to avoid errors defeats the purpose of that approach.

The procedure should execute in any case, even if there are errors in the procedure.

Now that you ask: Catch does block the execution. I see that the line where the error occurs the rest of the procedure is not going to be executed. So that's another problem, I have to execute each line separately to make sure all valid lines are executed, and the invalid lines are not executed.