>>>>Hi,
>>>>
>>>>I have a function that uses XFRX to convert a report to a PDF format.
>>>>
>>>>The report to be converted to PDF has multiple bands. XFRX handle it fine but the cursor names that are used for the bands have to be in scope inside the MyXFRX() function. And I used local variable. For example:
>>>>

>>>>local  Band1Cursor, Band2Cursor
>>>>Band1Cursor = sys(2015)
>>>>Band2Cursor = sys(2015)
>>>>

>>>>
>>>>With the above scenario the MyXFRX function gives an error that variable Band1Cursor does not exist.
>>>>
>>>>The solution - so far - is to either make the variables Private or hard coded. That is, do not use variables but instead use names like CUR_Band1, CUR_band2
>>>>
>>>>Which approach would be a better practice?
>>>>
>>>>TIA
>>>
>>>Variables declared as LOCAL are only visible in the procedure/function context where they are declared.
>>>Variables declared as PRIVATE are available in the procedure/function context where they are created as well as in context of called procedure/function. When a PRIVATE is used, variables listed In the PRIVATE statement that already exist as PUBLIC or as PRIVATE within the calling procedure/function will be "hidden" and assignment to the variable will create new instance at that level where the assignment takes place. Variables are implicitly declared as PRIVATE.
>>
>>Thank you. I believe I understand how PRIVATE variables work. But I am wondering if instead of PRIVATE variable I would be better using a hard-coded cursor names. Because hard-coded cursor names visible in the called procedure as well. Or, maybe, this is just six or half dozen.
>
>The disadvantage of Private variables is, that your code will not be encapsulated. That means, your method where you set the aliasnames, and the other method where you use the aliasnames are tightly coupled. That is basically the opposite of what you want to achieve, especially when you need to continue maintaining or expanding the software.
>
>If you hardcode the aliasnames this is pretty much the same as private variables only worse, because you cannot have another method using the same aliasnames. That means whenever you write a method you have to toe-tip between minefields trying not to break other code, be it because you are accidentally using a variablename that has been used private somewhere else, or same with a Cursor Name. So your approach to create aliasnames with sys(2015) is already a very good strategy.
>
>True encapsulation can be achieved through classes that encapsulate this behavior and provide an interface for the calling method.
>
>

>LOCAL loReportFRXHandler AS ReportFRXHandler OF Report_tools.vcx
>loReportFRXHandler = Newobject("ReportFRXHandler","Report_tools.vcx")
>
>loReportFRXHandler.Dowhatever()
>
>SELECT (loReportFRXHandler.Band1Cursor)
>SELECT (loReportFRXHandler.Band2Cursor)
>
>RETURN .T.
>

>
>The class could be implemented like this:
>
>

>DEFINE CLASS ReportFRXHandler AS Custom
>    Band1Cursor = ""
>    Band2Cursor = ""
>    FRXFilename1 = "Reportname1.frx"
>    FRXFilename2 = "Reportname2.frx"
>    
>    PROCEDURE INIT
>    THIS.Band1Cursor = SYS(2015)
>    THIS.Band2Cursor = SYS(2015)
>    ENDPROC
>
>    PROCEDURE DESTROY
>    USE IN (SELECT(THIS.Band1Cursor))
>    USE IN (SELECT(THIS.Band2Cursor))
>    ENDPROC
>    
>    PROCEDURE DoWhatEver
>    USE (THIS.FRXFilename1) ALIAS (THIS.Band1Cursor) IN 0
>    USE (THIS.FRXFilename2) ALIAS (THIS.Band2Cursor) IN 0
>    ENDPROC
>
>    PROCEDURE ManipulateStuff
>    SELECT (THIS.Band1Cursor)
>    APPEND FROM (THIS.Band2Cursor)
>    ENDPROC
>
>ENDDEFINE
>

>
>The advantage of this approach is that you can now expand this class with more functionality and properies, without ever needing to worry for private or hadcoded variables. In fact I have not used private variables in the last 15 years or so, never had the need for it, except in very particular cases, like when a report needed to print a value that was not in the cursor.

Thank you for your input and the sample code!