Hello Juan,

In this case I would probably not use the report.Dataenvironment.Init() for conditional filtering of the records for the report (or any other processing). I would do all the processing in the print button .Click() (which is on the form), and just run the report with no dataenvironment. My code usually looks like this:

** cmdPrint.Click()
local myParam1, myParam2, lcPreview
lcPreview = IIF (NOT EMPTY(thisform.chkPreview.Value), "preview", "")
myParam1 =  thisform.txtMyCriteria1.Value
myParam2 =  thisform.txtMyCriteria2.Value

SELECT * from Customers ;
where Customers.cCountry = myParam1 ;
and Customers.cState = myParam2 ;
into cursor myReportCursor NOFILTER

* some other processing may go here

REPORT FORM myReport1 TO PRINTER &lcPreview NOCONSOLE

***

HTH,

NIck


>Hello Nick
>
>You are right. I can print fields like thisform.anyvar, but i cannot use them
>in the init event of the report's dataenvironment because VFP says The object is not contained in the form (El objeto no esta contenido en el form)
>
>My idea is that the user types some range or criteria in the form and
>i filter records after opening tables (during init event of the report's dataenvironment) and before printing the report.
>
>Finally, I am using normal memvar in the form's fields and releasing them during the form's unload event. If i don't do it, the variables become public and i don't like it.
>This way, i can use those variables anywhere in the report and its dataenvironment's events.
>
>Am i right? I hope you understand me. You all are very kind.
>
>Thank you very much
>
>Juan Carlos
>
>>
>>If you run the report from the form (or any form control code) THISFORM does not loose the scope. I use this approach all the time.
>>
>>Nick