Here are some errors/omissions in the current version of the VFP7 documentation and some suggested improvements to add clarity:

1) Within the "[UNION [ALL] SELECT Command]" discussion of the "SELECT - SQL command", and under the example there, there is the following statement:
"Note Be sure to include the space immediately preceding each semicolon. Otherwise, you'll receive an error.".

Since no error is emitted when I do this, I conclude that the statement here is in error.


2) Within the "Remarks" section of the '&& command' is the following statement:
"You cannot place && and a comment after the semicolon used to continue a command line to an additional line."

This is incorrect and has been so for some time now.
I think that it might also be helpful to state, both here and in the documentation for the "& command", that a double ampersand (&&) will cause an error message if used within any command.


3) _INCSEEK system variable

.1) The syntax diagram shows "nValue" as the 'parameter' (right side of equal sign) but the "Parameters" section lists the name "nTicks".
.2) Does not state the default value for the nTicks (nValue) argument.
.3) Does not list where this is applicable (says only "such as within a Listbox.").
.4) "Remarks" suggests, in the last sentence, that uncoupling (from _DBLCLICK) is optional. I believe that this is incorrect - it is not optional to do this and _DBLCLICK will not longer function in the applicable controls.


4) The IncrementalSearch property

.1) Under the "Remarks" section it states: "Note that the setting of the _DBLCLICK system variable determines how long to wait for the next letter to be typed. You may need to adjust the value of _DBLCLICK to make incremental searching work properly.".
The new _INCSEEK replaced this in VFP7 and _DBLCLICK is no longer operational for this purpose.
.2) The "See Also" also lists _DBLCLICK where it should list _INCSEEK.


5) ADLLS() function

.1) The function preamble starts with: "Returns an array containing . . .". It does NOT "return" an array, it CREATES (or redimensions) an array and "RETURNS" the number of rows created.
.2) The second sentence of "Remarks" says "If no alias is provided. . .". This wording caused me to re-check the syntax diagram to learn how I "provide" that argument. I believe it would be much clearer to state something along the lines of: "In column two of the array filled by this function, for any DLL declared without the "As AliasName" clause. . .".
.3) The CASE of the content within individual columns filled should be stated.


6) ALANGUAGE() function

.1) The function preamble starts with: "Returns an array containing . . .". It does NOT "return" an array, it CREATES (or redimensions) an array and "RETURNS" the number of rows created.
.2) There is no "Return Value" section in the documentation.
.3) There is no mention anywhere that the function returns the number of rows created. My simple testing shows that it does return a numeric value, which I assume to be the number of rows in the array filled by the function.
.4) The CASE of the content within individual columns filled should be stated.
.5) The "Examples" section is poorly worded, suggesting that the resulting array, FuncArr, will contain only 3 rows. And even the example gives no clue that the function returns the number of rows created.


7) APROCINFO() function

.1) The function preamble is vague.
---- What is a "language element"? [at least this one says "Creates an array" though].
---- Based on this description one could assume that a parsed version of the entire program is returned.
.2) There is no "Return Value" section in the documentation.
.3) There is no mention anywhere that the function returns the number of rows created/filled.
.4) There is no mention, anywhere, of the CASE of the character output in the array. Many other functions return all upper-case. Whatever the situation here (seems to be mixed case), it needs to be stated.
.5) Under "Parameters" --> cFileName (or anywhere else) there is NO MENTION of the handling/output for a .PRG that contains multiple PROCEDURES/FUNCTIONS. This remains common practise in the VFP world.
.6) Regarding the first table in the discussion:
----a) Under "nType" for the 0 value the right parenthesis is missing from "(default".
----b) Under "Description" for all nType values, what is the "document" that is mentioned??? Why change the terminology in mid-stream???
----c) Under "Array Details" for the values 0, 2 and 3, what is "Doc View content"?
----d) Under "Array Details" for ALL rows, what is the TYPE in each column created? For example, is column 2, "line", a character element containing the actual code line or might it be the line number (which testing suggests it is). If it is a line number, is it numeric or is it character or is it integer or what?


8) ASESSIONS() function

Overall this function's documentation is reasonably well done. It could be improved by:
.1) Mentioning in the preamble that it returns the number of rows created.
.2) Mentioning the fact that the array created is 1-dimensional.
.3) Mentioning the TYPE of the content of the filled column.


9) ASTACKINFO() function

.1) Regarding the preamble (brief description preceding the syntax diagram):
----a) Starts with: "Returns an array that provides . . .". It does NOT "return" an array, it CREATES (or redimensions) an array and "RETURNS" the number of rows created. [at least I PRESUME that it creates the array, since this is not mentioned in fact at all through the entire discussion]
----b) The statement " . . . provides information about an object in the currently . . ." is not clear. What object?...How is that object specified? It would be somewhat more clear if the statement was, as found within the "Remarks" section, " . . . with information about the entire calling stack.".
.2) Under Parameters --> ArrayName :
----a) Does not mention (as virtually all other array-related functions do) that the array is CREATED. As presently documented one would conclude that the array must exist before calling the function. I doubt that this is correct, but if it is then it should be stated explicitly.
----b) The statement " . . . information about the examined object." is not clear. What object? ... How is that object specified?
----c) The table describing the column content does not define theTYPE of each column content.
----d) The table describing the column content does not indicate the case of any string columns.
----e) The title for the first column in the table would be clearer if it said "Array Column" instead of "Array Element".
.3) Under the "Remarks" section:
----a) The third paragraph has "ASTACKINFO()" misspelled as "ASTACKIINFO()".
----b) It would be helpful if there was a sentence or two to describe what the "calling stack" is.
----c) It would be helpful to list (if it is the case) any commands/situations that do NOT affect the content of the 'calling stack'.
----d) It would be helpful if there was a sentence describing the ORDER that the stack information is stored in the array. If it is "first to last" then say so! [don't leave the reader to guess, based on the sample output]
----e) It would be helpful if there was a sentence or two to describe, IF APPLICABLE, any variations in the array content that might be dependent on "StartMode". [the "example" suggests that it may matter]
----f) It would be helpful to have a sentence to state if the function operates correctly in BUILDERs as well as in applications.
.4) Under the "Example" section:
----a) Does "&& Stack level = 1" represent the TOP of the real stack, or the BOTTOM?
----b) Element (1,3) looks like it shows more than just "&& Object" to me.
----c) All elements (x,6) state "&& in the source". This is meaningless. Looks like it should say "&& Source line content".


10) ATAGINFO() function

.1) There is no mention anywhere that the function returns the number of rows created or filled.
.2) Under "Parameters" -->cCDXName:
----a) Does not mention that the table associated with the .CDX or .IDX has to be OPEN. My simple test using a .CDX name for a table that was not open (but exists) gave 0 as the return value.
.3) Under "Remarks" section:
----a) The case of the array content is not mentioned. Since it is all always upper case, it should be mentioned.
----b) IF (repeat: IF) there is some significance to the order of the array content, then this should be mentioned.


11) COMPROP() Function

I suspect strongly that this is a very valuable function. Yet, from the (entire) discussion I can tell you that I have no idea as to what it really does, when I could employ it or why I would use it. In other words, I could never use this function based on what is discussed here! [I thought that the purpose of the "Language Reference" was to permit me to USE the commands/functions/etc. that it describes]

.1) For cProperty of "UTF8":
----a) What is UTF8?
----b) What is UNICODE?
----c) Does this apply to VFP COM objects or to 'outsider' COM objects?
.2) For cProperty of "PUTREF":
----a) What is "PROPERTY-PUT"?
----b) What is "PUTREF"?
----c) Does this apply to VFP COM objects or to 'outsider' COM objects?
----d) It states ". . .initial object assignment . . .". Is there a difference between "initial object assignment" and 'subsequent object assignment"?. . . Why does this say "object assignment" when the preamble speaks of PROPERTY (not object)?
.3) The "Descriptions" for both 'cProperty" UTF8 and PUTREF both start with: "Determines. . .". Do not both of these also "specify" as well as 'determine'?
.4) Under the "Example" it states "returns data from methods of an ADO recordset as UNICODE instead of allowing conversion to ANSI". Am I correct in ASS-U-MING from this that there is no problem processing UNICODE in VFP and that there is nothing (else) special that needs to be done to do so successfully?
.5) This is one of a few new functions that *appear to* endow us (the developers) with significant extra power to deal with COM objects. Yet I can find nothing going into detail on this collection of new capabilities. There must be something somewhere. Once there is, it needs to be linked-to from each of the related commands/functions like this one.


12) LOCAL command

.1) The syntax fails to include options/clauses that are described under the "parameters" heading. These missing clauses are:
---a) AS type
---b) OF ClassLib
.2) The syntax diagram also strongly suggests that arrays are to be coded in separate LOCAL statements from memvar LOCAL statements.
This, apparently, is not correct and both types of variables can be successfully coded on a single LOCAL statement provided that the ARRAY keyword is omitted. This could be mentioned.