>>>You also do not have to use -> anymore between the table and field names. You can replace it with a .
>>Most of the time.Try this:
>>open a table
>>lcTableName = 'part' && table name
>>lcFieldName = 'partno' && field name
>>?part.&lcFieldName &&gives the value of part.partno
>>?&lcTableName.&lcFieldName &&gives an error
>
>The problem is that macro-expansion interprets the first '.' as a macro termination indicator; try &lcTableName..&lcFieldName or EVAL(lcTableName + '.' + lcFieldName) or
>
>lcMyField = lcTableName + '.' + lcFieldName
>? &lcMyField
>? EVAL(lcMyField)
You're right about. My point was that you might not want to go through old code doing a mass REPLACE of '->' with '.'
>
>>?&lcTableName->&lcFieldName && gives the value of part.partno
>>Whatta ya think?
>>
>>>
>>>>Hey UT folks -
>>>>Sometimes I feel like a total idiot savant with VFP. Some features I know as well as the people who designed them, then I hit something like this .. which is probably something everyone but me knew about.
>>>>
>>>>Here's the feature I didn't know about, but came across by accident:
>>>>
>>>>Did you know that when you issue a SCAN/ENDSCAN VFP automatically flips a SELECT back to the correct file when hitting the ENDSCAN without you having to explicitly doing so?
>>>>
>>>>Here's an example program:
>>>>
>>>>SELECT j1
>>>>
>>>>SCAN
>>>> SELECT j2
>>>> LOCATE FOR ord = j1->rec
>>>> IF NOT FOUND()
>>>> APPEND BLANK
>>>> REPLACE ord with j1->rec
>>>> ENDIF
>>>>ENDSCAN
>>>>
>>>>Now I would have expected this to bomb, because I didn't issue a 'SELECT j1' after the REPLACE and there's no 'ord' field on the 'j2' file. But when the program hits the ENDSCAN, it reverts to 'j1' automatically!
>>>>
>>>>Please someone tell me this is new and not been around since VFP 3 or FoxPro 1.0. Yeesh!