>>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.