Here's my 2c :

In the answers so far I found two being the most near to my opinion :

Mike :

.cExpression
The optional period (.) delimiter and .cExpression are used to append additional characters to a macro. cExpression appended to the macro with .cExpression can also be a macro. If cExpression is a property name, include an extra period (cExpression..PropertyName).

Jay :

My recollection is slightly different. The period is (for who knows what reason!), the concatenation operator in macro substitution. So, the first period marks the concatenation and the 2nd period the actual period separating table and field names.

Just using 1 period doesn't work because the period separator isn't included.


While Mike refers to the Help, that may be right but not so much clear;
Jay translates this into "concatenation" and that is just what it is. So, nothing about indicating where the macro-part ends, but just concatenation which can't be done with the usual "+" (in many macro-cases).

The above is the first part (i.e. first dot) of the answer;
The second part is about the second dot, which -again- Mike (the Help) explains as how it is, but which is again not clear, because we are not talking properties here, but a filename and field. Thus, where Jay is literally right on his explanation, it is not generally enough;
Just understand this (and shoot me when I'm wrong) :

When OO was introduced, a field in a table was "looked at by VFP" as the resolution operator for an object and it's property, IOW the table being the object and the field being the property. I wonder whether THAT is somewhere in the Help, and anyway, this is my assumption. It is the same as m.VarName opposed to TableName.FieldName. So, the memory being another object opposed to the Table. Note that in the old days (still working) this was m->VarName and TableName->FieldName.

Now when the above is taking into account we just understand all of it, and the second dot is just working out the reference of an object, being a real object or a tablename;
The first dot acts as a concatanation which is just needed when a macro is referred to as &MacroExpression, also noting that NOT all Macros can be referred to as (MacroExpression) so the &MacroExpression..ObjectReference is unavoidable in according cases.
If one would say that the first dot ends the macro expression, a sole &MacroExpresssion. would be allowed, of which I'm sure it isn't (I don't even start trying).

There is a lot, lot more to macro's, and as far as I know there is relatively nothing in Fox' Help.

Shoot me,
Peter




>Hi all,
>
>Hey everyone... We were having a discussion with a junior programmer about macro expansion and the topic of usung double dots came up. Actually discovered this quite by accident and I had to admit that while using double dots has been around for ages I couldn't remember all of the reasons and justifications for its implementation.
>
>For example:
>
>Temporary cursor named "cResults" containing fields named "cXML1", "cXML2" & "cXML3".
>
>Well, I pointed out to Jeff that you could do something like this:
>
>cDBF = alias() && cResults
>cField = "cXML" + alltrim(str(nLoop)) && 1, 2 & 3
>
>and then do this:
>
>? &cDBF..&cField and you'd get the proper field.
>
>For the life of me I can't remember the reason we needed to use double dots but after talking to Craig Berntson he suggested that one might indicate the end of a macro expansion and the second dot was interpreted as the 'normal' dot used when referring to a table plus field.
>
>This seems the most accurate but I was wondering if any of you old timers <g> might remember anything additional to this.
>
>This also works for situations like "THISFORM.&cTextbox..value" which would also make sense, given the presumption above.
>
>Thoughts??
>
>Best,
>
>DD