---
but to me it appeals to to document the code within the code;
it is a fast and sure mode.
---

I agree. That's why I have used variants of the #IF .F./TEXT ENDTEXT/#ENDIF method for a long time. If you do this at the top of your methods, similar to javadoc, you can easily create documentation for the results. (NB: even in this strategy, using XML has advantages, or you can use one of the many tagging conventions already available for this purpose.)

I have extended this strategy in many different ways for developer-clients who needed extensible documentation systems.

From the little I've seen of your posts, I would not think to assume I know exactly what *your* documentation requirements are but I am comfortable stating two things:

1. This technique can work for you, it would suit your needs, and

2. You have the ability to create the necessary parsing routines and to work out the extensions that best suit you. <s>

---
I will think to use Memberdata.
The first thought negative:
how I make with the classes that they do not have one VCX support (you see columns
---

Not a problem, just create the _MemberData member. For example:

PUBLIC ox && this is just so you can call ox.mymethod()
          && from the commandline after this little program runs
          && and verify that the capitalization is in fact
          && camelcase

ox = CREATEOBJECT("x")
oy = CREATEOBJECT("microsoft.xmldom")
oy.loadXML(ox._memberdata)

IF LEN(oy.XML) > 0
   oz= oy.selectSingleNode("/VFPData/memberdata[@name='mymethod']")
   ? oz.getAttribute("myattrib1")  && or whatever
   * in reality for documentation purposes you would just
   * iterate through a collection of nodes here.
   * or (what a concept!) just transform the thing   
   * without bothering to traverse the DOM, with XSLT.
ENDIF   

DEFINE CLASS x as Column

   PROCEDURE MyMethod(toWhatever)
   RETURN .T.
   ENDPROC

  _MemberData="<VFPData>" + ;
              "<memberdata name = 'mymethod' display='MyMethod' " + ;
                " myattrib1='Parameters description here' "+ ;
                " myattrib2='Return values here'" + ;
                " myattrib3='Method description here'/>" + ;
              "</VFPData>"
ENDDEFINE              

I personally have no desire to do the above, and I also personally prefer PRG classes to VCX in the first place. Besides, I *am* javadoc-oriented <g>. But for standardization purposes and the ability to compress a lot of organized meaning into a single text object, you can't beat XML <s>.

I have toyed with a related idea, which is to use one of the reserved fields that still isn't used, or another custom property, to store XML documentation the way I would prefer for a class: as an attached file, like a second #INCLUDE. I would still probably keep the memberdata schema so that other people could use it easily. Obviously this would work as well for PRG as VCX classes!

>L<