DTOR() | Hackers Guide to Visual FoxPro 7.0

AProcInfo(), EditSource()

These two functions offer programmatic support for the Document View and Task List tools added in VFP 7. AProcInfo() fills an array with a list of the components of a program file and their locations. EditSource() opens any VFP file in the appropriate editing tool.

Usage

nCount = APROCINFO( ArrayName, cFileName [, nItemType ] )

Parameter	Value	Meaning
ArrayName	Name	The array in which the list of components is stored.
cFileName	Character	The file (possibly including a path) for which component information is extracted.
nItemType	0 or omitted	List procedures, classes, methods and compiler directives in the array.
	1	List only classes in the array.
	2	List only methods in the array.
	3	List only compiler directives in the array.

AProcInfo() collects information about where things are in a program file. It works only for program files (though the actual file extension doesn't matter). Interestingly, the function doesn't barf if you pass it a different file type—it just returns 0. As with the other array functions, the array is created or resized as needed.

The structure of the resulting array (including the number of columns) varies depending on the value passed for nItemType. Here's an overview. (We'd sure like it if FoxPro.H had constants for these.)

Column	Meaning	Applies for nItemType
1	Name of item. For methods, the name includes the class name. For classes, includes the "AS" portion of the definition listing the parent class.	0,2,3
1	Class name.	1
2	Line number in the file where the item occurs.	All
3	Item type: Define, Directive, Class, Procedure. All procedures, functions, methods and events are classified as "Procedure."	0,3
3	Parent class name.	1
4	Indentation, but always 0.	0
4	If the class is defined OLEPublic, "OLEPUBLIC". Otherwise, empty.	1

The docs say that, with nItemType = 0 or omitted, the fourth column of the array contains indentation. In our experience, regardless of the indentation of the source file, this column always contains 0.

Pay attention: The type of the fourth column depends on nItemType. When you pass 0, it's numeric; if you pass 1, it's character.

For some reason, the list of choices you have for nItemType doesn't exactly correspond to the filters offered for Document View. The function actually offers more fine-tuning than the tool, though the tool lets you decide how to sort the results, which the function doesn't. Even worse, you can separate out all but one type—procedures in the same file as class definitions have to be extracted the hard way.

The array shows the descriptor "Procedure" for both procedures and methods, but you can tell the two apart anyway. Methods are listed as "ClassName.MethodName" in column 1.

Example

* Suppose you have the following in MyCode.PRG: #DEFINE Fred Ethel #DEFINE Lucy Ricky   PROCEDURE Irving RETURN   DEFINE CLASS Martha AS Form   PROC George ENDPROC ENDDEFINE   * You can apply AProcInfo(), as follows: ?APROCINFO( aAllStuff, "MyCode.PRG" )     && Returns 5 ?APROCINFO( aClassList, "MyCode.PRG", 1 ) && Returns 1 ?APROCINFO( aMethods, "MyCode.PRG", 2 )   && Returns 1 ?APROCINFO( aDirectives, "MyCode.PRG", 3) && Returns 2

Usage

nErrorCode = EDITSOURCE( cShortCutID |                           cFileName [, nLineNo                           [, cClassName [, cMethodName ] ] ] )

Parameter	Value	Meaning
cShortCutID	Character	The ID for the shortcut in the task list for the item to be opened.
cFileName	Character	The file name (including path) of the file to be opened.
nLineNo	Numeric	The line number within the editing window where the cursor should be positioned.
cClassName	Character	The name of the class to be opened.
cMethodName	Character	The name of the method within a class or form that should be displayed in the method editor.
nErrorCode	0	The file was opened successfully.
nErrorCode	Any other number	Something went wrong. See Help for a list of error codes.

EditSource() is one of those functions where a syntax diagram doesn't begin to tell the whole story. This function can be used to open virtually every kind of file that VFP handles. The parameters you should pass and their interpretation vary with the file type.

The simplest way to use EditSource() is no doubt the reason it was added to the language. If you pass it a shortcut ID (as stored in the Task List table), it opens the appropriate file at the specified location. End of story.

Passing the information directly is much more complex. The easiest, but usually least useful, thing to do is to pass just a file name. In that case, the specified file is opened in its native editor. (See Help for a list of the editors associated with the various file types.)

After that, it gets complicated. For text-based files, including PRG files, TXT files and a database's stored procedures, the only other parameter that matters is nLineNo. Pass it and the file opens to that line.

For class libraries, things aren't so bad, either. If you pass just the file name or the file name and a line number, the Open Class dialog appears for you to choose a class within the library. Add the class name as the third parameter to open that class directly. Finally, you can specify a particular method to open in the method editor by passing it as the fourth parameter. If the method belongs to a member of the class or form, use the "MemberName.MethodName" format, as in "Command1.Click".

Forms do things more or less the same way as class libraries, except that you specify "Form" as the class name, in order to get to a particular method.

Menu designs (MNX files) ignore any parameters after the file name, while generated menus (MPR files) behave like other text-based files. Report (FRX) and label (LBX) files behave similarly—only the file name parameter is relevant. Help suggests that you can go right to code inside a report or label, but we haven't found any way to do so.

The original release of VFP 7 has one of the strangest bugs we've ever come across. If the third parameter you pass to EditSource() contains a period (say, "x.y"), VFP crashes dead. While we're not sure why you'd pass such a string for the class name, keeling over is pretty rude behavior. Fortunately, it's fixed in Service Pack 1.

Example

? EditSource( HOME() + "GenHtml.PRG", 100) ? EditSource( HOME(2) + "TASTRADE\FORMS\BEHINDSC.SCX", 1, ;               "Form", "cmdClose.Click" )