>>>Yes, that will surely work, but I think Puri will also benefit from mentioning the possibility of stating

_Screen.ActiveForm.property

in the report field, or any other UDF outside the active form for that matter
>>>
>>>Best
>>
>>Are you guys doing this? I know you can't use thisform. in the report, since the report is not contained in a form.
>
>Bob,
>
>Ehhh you're right. The Thisform.Syntax won't work. Sorry about that.
>
***
I use only ThisForm.property approach in all my reports, and it does work for me, but I have also tried using _SCREEN.ActiveForm.Property. It worked just as nice, but I thought I'd stick with one way, so I went on using Thisform...

Daniel
***

>Marc
>>
>>Using _screen.activeform.property may work, but what happens when the print screen gets focus?

You tell me what happens; print screen is not a form as far as I see

>>
>>How about declaring a private variable with a reference to the form?
>>
>>private opCallingForm
>>opCallingForm = this
>>
>>This in the report you would access...
>>
>>opCallinForm.property
>>
>>Of course, then the report would need to be hard coded to always use opCallingForm...
>>
>>Perhaps you can also create privates of the form properties...
>>
>>private var1,var2,var3,var4
>>
>>var1 = thisform.var1
>>var2 = thisform.var2
>>var3 = thisform.var3
>>var4 = thisform.var4
>>
>>report form ...
>>
>>BOb

I see the logic here, but I still prefer my report class, always works, always gets the right report, and the only variable is frx name

Cheers