>Why not make this by the same way as in other languages?
> For example, in SQL Server I can use following:
> MyString = 'Ed''s new book "How to confuse FoxPro"'
>

I don't know why the parser doesn't use this syntax, but because of parsing issues that likely would arise in macro-expansion embedded in concatenations, not supporting it generally isn't annoying; all I know is the syntax isn't used by VFP. And embedded \n in a string isn't treated as a newline, a backslash is represented as \ not \\, and a null (CHR(0)) doesn't force a VFP string to terminate.

You can make a string containing all three sets via concatenation, but you often cause yourself problems if the string with embedded string delimiters is later re-parsed (ie used in a macro-expansion or EVAL().) For me, the main reason I make frequent use of the square bracket pairing is the use of the ' and " in names and addresses that I may want to use with macro-expansion where the expanded string will need explicit delimiting.

> In VFP I cannot make string constant that contains all ', " and [] characters :(
>
>>>I have been looking through some code and have found the following:
>>>
>>>m.lookup = [ text text text ]
>>>
>>>When I tried this, it seems that it has made it a text variable.
>>>
>>>I have looked on MSDN library for some documentation on this, since I have never seen this, and could not find anything.
>>>
>>>Could anyone point me to documentation for this or explain when and why you would use the above?
>>>
>>
>>VFP offers the option of encapsulating strings in three ways - using single quotes - ' text text text ', double quotes - " text text text " or matched pairs of square brackets - [ text text text ]
>>
>>The reason you'd choose one over the other is ease of use - if you wanted to place the phrase Ed's new book "How to confuse FoxPro" in a single string, and you didn't have the option of using square braces, you'd have to split up the string. You can do:
>>
>>cMyString = [Ed's new book "How to confuse FoxPro"]
>>
>>or
>>
>>cMyString = "Ed's new book " + '"How to confuse FoxPro"'
>>
>>to avoid having the parser misinterpret the string. It's a matter of flexibility, and has been a standard for Fox and other dBASE-derived languages for as long as I can remember.