>>
>>It should, but.
>>
>>With code called from within a report, you never know how many times it is called. Specially if there's a preview going on - to show page 7, VFP evaluates and sizes up everything on pages 1 through 6, then renders page 7. Which means that any code in the expressions on these pages is also run when the expressions are evaluated - some of them twice (not sure this still holds, I observed it in several versions of VFP, but don't remember which). If you're using _pagecount variable, whole report is run just to calculate the total number of pages - and all the code on each page too (some of it maybe more than once).
>>
>>I hope you got the picture. My guess is that it will work, but you'll get a few surprises, aka "unexpected behaviors".
>
>Thank you for your input. I can see how things can get "complicated". And I actually thought, after I posted the message, that what I am trying to do using this function call from an Expression is not such a good approach (for other reasons than how VFP does it). I have to rethink everything.

Even when it works, the "calculate it within the report" approach was somehow always disappointing to me. Very soon it would get into something that just can't be done that way, or would get too complicated, or (the worst) was actually needed somewhere outside of the report, so it had to be repeated in a different form. Which eventually taught me that having intelligent report is a fine but futile art. Preparing the data to report is, IMO, best done in a piece of code - SQL plus some grinding - and the display of the results is where a reporting engine should be in charge. Then if that code needs to be reused elsewhere (a bizobject? another report? grid with totals?), it can be.