Hi Erik,

>At design time, you cannot dependably resolve THISFORM to the active form with _SCREEN.ActiveForm, or SYS(1270). So even if we could catch every key in the editor window, getting an actual object reference to the object in question would be pretty tricky. (Any ideas? You've amazed me plenty of times before...)

Take a look at SuperCls. There's only one problem that I've found (and which Ken Levy hasn't solved either *g*). OK, let's look step by step:

There are three places where Intellisense must be implemented: a) the command window, b) MODIFY COMMAND windows and c) Method code windows. In the command window you usually have an object reference, so there's no problem here. Part b) is more complex, so let's step over to c:

VFP knows to which object each method window belongs. With the meanings of VFP you can only guess here, as the only way to identify the object and method is the window title. You can use ASELOBJ(), the Forms() collection, etc. to find the most probable object, if several objects have got the same name, but that's a different story.

Since VFP knows that, it can resolve any reference inside the code that refers to THIS, THISFORM and THISFORMSET. With WITH...ENDWITH it's a bit more complex, especially if they span multiple methods, but I bet that VFP will fail here, too. For object reference variables, they introduced a new keyword, as far as I could see. You can write LOCAL oForm AS FORM. This way, the object reference can uniquely be identified as a certain class. Once you know the class, it's no problem to either access the VCX or use several VFP functions like AMEMBERS, GETPEM, etc. to determine all methods and properties. If you have a method, it's no problem to read the LPARAMETER statement and display it.

If you have a MODIFY COMMAND window and you simply write code, the new LOCAL AS syntax helps you. Inside a class definition there's no problem either. The actual problem is when a class in code inherits from another class that is not in the PRG file you are working on. Here I would assume that VFP uses all currently loaded class libraries, and all recently loaded class libraries. Maybe it even parses for a SET CLASSLIB statement, but Intellisense could probably only guess here. One way around would be an extension to the DEFINE CLASS command where you can specify the class library, but maybe they don't use such things.

IOW, with the current VFP syntax you are indeed limited to the class you are working on and have to skip object references stored in variables. But if you define some additional tokens, maybe like GenScrnX: *:DIM loRef AS SomeClass, you should be able to implement IntelliSense in VFP 6, once you solved the problem with the keystrokes.

If I think about that, it's not necessary to capture all keys, just a few like ".", ":", "(" and "[". If those keys are pressed, you verify whether there's something you can display and enter IntelliSense mode. Now you read every keystroke (just like a plain old INKEY()). If it's something in your list, you write the character into the edit window and requery the list, if it's a different keystroke that you can't handle, you just repeat it after quitting IntelliSense mode. You can capture mouse clicks the same way and exit ItelliSense mode if the user clicks anywhere on the screen.

>>Taking this into account and looking at the possibilities that are available in VFP and the VFP API, all we need is a hook to capture every single key stroke instead of just reacting on the SpaceBar or something like this, and we are practically done.
>
>Agreed. This and solving the difficulty of object resolution above woud get us all the way there. I was actually hoping that you knew of a way to fire code on every keypress...

Sure, you can hook into the VFP event queue in the VFP API using a FLL. But the problem is that you can't execute VFP code from this hook. But for the VFP development team it should be easy to develop something like the ON KEY command, ie. execute some VFP code on every WM_KEYDOWN, etc. message.

>>Reading the current line in the editor window is easy,
>
>I believe you, but how?

Just like CEE is doing it, by using the _ED...() API functions that are even available in FoxTools.Fll.

Christof