last week i began a discussion of the vfp intellisense functionality by talking about the configuration of intellisense and how to control its various features. the foxcode.dbf table lies at the very heart of the vfp intellisense functionality and understanding how it is constructed and used is the key to making full use of the power of intellisense. so, at the risk of duplicating information that is already in the visual foxpro help files, here is the structure and a brief explanation of how each column is used by the intellisense engine.

table 1:foxcode table structure





c (1)

identifier which defines how the record should be processed:

        c (command)  auto-complete items. triggered by “ ”

        f (function)    quick info items. triggered by “(“

        o (com)        the type library to use when populating the members list for “define as” declarations for com objects

        p (property)     define actions when a property is accessed

        s (script)       execute the script in the data field

        t (type)          the contents to use in the members list for “define as” declarations or for objects that do not have type libraries

        u (user)        user-defined

        v (version)     reserved for default/version information

        z (special)     no automatic interpretation, define custom behavior


c (24)

abbreviated string to trigger the specified action


c (26)

the string to replace the abbreviation with, where appropriate


c (15)

the name of the script to execute for this item. enclosed in “{}”


m ( 4)

the contents to display as a quick tip


m ( 4)

holds any content for this record. (list values, code, script text etc)


c ( 1)

specifies how expanded text is formatted to replace abbreviated text

        u = use upper() function to format

        l = use lower() function to format

        p = use proper() function to format

        m or <empty> = no formatting applied

        x = no replacement applied

note: the value specified in the ‘version’ record defines the default to be used for any record that does not have its own setting.


l (1)

flag to indicate whether record is preserved during updates (false for native items)


t (8)

timestamp (vfp items only)


m (4)

the source to use for record content. (native items use “reserved”)


c (10)

unique id (vfp items only)


m ( 4)

available for any user-defined information that is needed


the advanced tab of the intellisense manager form includes options to restore the foxcode table. this means that if the table gets damaged, or even if you inadvertently delete or change some critical entry, you can simply restore the table to its original state. the nice thing about the restoration is that it will not destroy your custom items. the timestamp, uniqueid and save fields are used whenever updating or restoring the foxcode table to determine the origin of the data and whether it may be overwritten. by default the native visual foxpro entries have both a time stamp and a unique id, but their save field is set to false so that they can be overwritten. user defined entries, on the other hand, do not have either a unique id or a time stamp, but the save field is set to true so that when the table is updated, or refreshed, your user-defined items are preserved.

how foxcode records are used

each of the record types has a very specific set of functionality associated with it, and the different types indicate how the fields are interpreted by the intellisense engine.

version record (type = “v”)

there is only one of these and it is intended for internal use by visual foxpro. the expanded field contains the version number for the current foxcode table, and the case field defines the default setting for any item that does not have one set.

command record (type = “c”)

this type is used for defining auto-complete text that is triggered by the space key and which use the “default script” that is defined in the data field of the record with type = s and an empty abbrev field. all of the native commands use this methodology. however, you can also create your own ‘commands’ that explicitly associate quick info (from the tip field) or a members list (from the data field) by defining an abbreviation and including a call to the command handler script ({cmdhandler}) in the cmd field.

function record (type = “f”)

this type is used to define auto-complete text that is triggered by the left parenthesis character “(“. in this record type the contents of the tip field are used to display the ‘smart’ quick info tips that track parameter entry by matching the pattern of the text you type with that defined in the record.

property record (type = “p”)

this type is used to assign a pop-up dialog (or value list) to be displayed whenever a value is assigned to a property whose name matches the entry in the abbrev field. the cmd field is used to indicate whether a script defined elsewhere in the table, or the contents of the data field in the current record, are to be used to generate the list. the version 9.0 foxcode table ships with several generic scripts that are used with this record type. for example one (named {color}) displays the color picker dialog and is associated with a number of color definition properties (e.g. “backcolor”, “bordercolor” and “fillcolor”). another (named {picture}) displays the open picture dialog whenever either an “icon” or “picture” property is assigned and there are also scripts for {font} and {memberclasslib}.

com component record (type = “o”)

this type is used to define, to the intellisense engine, the type library for a com component (or activex control). the data field is used to store the guid (and version) information, and the tip field to store the full name of the control. the content of the abbrev field is included in drop down list of objects associated with an as clause (define class…as…, local…as… ). however, the easiest way to add a com object to the table is to use the intellisense manager that ships with vfp because it avoids the necessity to go hunting in the registry for guids and class ids.

typing record (type = “t”)

this type is used to define an entry for the drop-down list of an as clause. the difference between this type and preceding “o” record type is that there is no type library associated with this record type. thus your own personal classes can be added to the drop down list displayed by the define class command. the content of the data field is displayed directly in the drop down list and this is the only field that needs to be completed. however, we do recommend adding a description to the abbrev field to make maintaining the table easier, and if you add text to the tip field it will be displayed as you scroll over the entry in the list.

user record (type = “u”)

this record type is used to identify abbreviations for user-defined content. it differs from the command type in that it replaces the content of the abbrev field with the content of the expanded field. instead of just ‘completing’ text, it actually substitutes text – more like a keyboard macro than an auto-complete. there is no need to have the expanded text related to the abbreviation that triggers it.

you can also associate a script with a user type record by including empty braces (“{}”) in the cmd field. this indicates to the intellisense engine that the data field of the record contains script code that is to be executed.

script record (type = “s”)

this type is used to store code as named scripts that can be executed by the intellisense engine. to create a script all that is required is the name in the abbrev field and the code in the data field. other records can trigger the execution of these scripts by including the name (enclosed in braces “{}”) in their cmd field.

whilst “s” type records are used to create “generic” scripts that can be used by more than one entry any record type (with the exception of “t” and “o” records) can include a script in its own data field. however, in order to execute those scripts, a pair of empty braces “{}” must be inserted into the cmd field.

custom extension record (type = “z”)

this type is not covered by the documentation and is reserved for records that intellisense does not process automatically. there are two of these by default. the first “custompems” is used to store the ‘advanced’ configuration property information. the tip column contains the prompts for display in the intellisense manager, while the data column contains the settings as a list of attribute=value pairs. the second, named “customdefaultscripts“ is used to list the scripts that can be called by the default script handler (i.e. the space bar). the scripts named in this field are only activated when the “lallowcustomdefscripts” configuration property is set to true.

memberdata extension (type = “e”)

introduced in version 9.0 this type is used to indicate that the associated data is concerned with the extensibility offered by memberdata. for a full discussion of memberdata see the vfp 9.0 help file.


next time we will look at how to create customized intellisense actions, and how the various record types are used in visual foxpro.



4 Responses to Customizing IntelliSense – II

  • Dave Birley says:

    Thanks Andy — just wanted you to know I am reading these, and gradually increasing both my knowledge, and, more importantly, my understanding of IntelliSense.

  • Anonymous says:

    Nice to know that someone is reading them <g>

  • Anonymous says:


    I’ve found your tutorials on Intellisense very helpful. Have you come across any "ports" of Intellisense to textbox and editbox controls? I’m using VFP 9 and would like to extend the runtime Intellisense features to standard controls vs. just VFP’s "modify command" editor windows.


  • Anonymous says:

    I am not sure what you mean by "ports". VFP 9.0 supports a limited subset of intellisense functionality at run time natively – you just have to enable it. See the topic "IntelliSense Support in Visual FoxPro" for details.

    Autocomplete is also implemented for textboxes, but not edit boxes. Marcia and I wrote a FoxTalk column on how to enable auto-complete for Edit Boxes (see "Take Note" in the July 2004 issue of FoxTalk)

Leave a Reply

Your email address will not be published. Required fields are marked *