>I don't see much of a problem here. If the functions are used for report only, you can define them as methods of your object. But I think, having them as separate functions and not object methods might be quicker.

Humm, my guess was about If there isn't something better.. I also don't see exactly a problem... I just imagine if is this yet a good pratice... because "set procedure to" brought an idea of something so "procedural" to deals like report's liteners and stuffs..

But, anyway seems that I'm not so outdated as I thought...

Maybe it is because just by now I really start to deal with vfp9 report's engine.. And some pratice seemed old stuff..

Claudio
>
>>Hi UT's fellows..
>>
>>Some reports of mine usually use some UDFs on reports's fields to calculate or get any external data or procedure.
>>
>>I've been defining those UDFs on external programs (using set proceture to).. And, I always ask me if is it a good pratice for VFP9 (that culture I brought from fpw)...
>>
>>I mean... this is a basic structure for my applications
>>
>>...main prg
>>......objects
>>......objects
>>......objects
>>......objects
>>......object that control and call reports ((------- all external procedures is declared here with "set procedure to"
>>
>>Is it good pratice? Polically correctly?
>>
>>Is it something structurally better? on terms of speed...
>>
>>TIA
>>
>>Claudio