Thanks for looking at this. The typos were only on the UT, not in my code. Both of these return the OLE error of interface unsupported:

loAPI.GetAVals(lcGUID)
loAPI.GetAVals((loAObject.id))

However, an interesting note is that if I pass the var lcGuid, I receive 'no such interface supported' but if I pass the object, I receive 'The parameter is incorrect' because it expects a Guid.

Now, if I create a session object and hook up one of the events to it, it fires, but only locally and it appears that only the code in the procs in the define below run, not the base code in the dll. For example, I dragged the interface onto a foxpro prg and it fires, but it doesn't communicate back through the dll. It's like it only fires locally:

x=NEWOBJECT("aClass")  && tried for the main connection
z=NEWOBJECT("abClass") && tried for the object
EVENTHANDLER(a,z)   && tried hooked it to the main connection
EVENTHANDLER(ab,z)  && tried hooked it to the object

*--This returns a connection number:
x.aClass_Connect(5000)        && returns a connection number as though connected
loABOject.aname = 'Tracy C Holzer' && this is set - I can see the value in the same object created earlier
x.aClass_SetAVals(loAbObject) && runs and I im in the proc below, but doesn't pass anything - no real connection
*--In x.SetaVals I can see the values in the debugger locally, but nothing is changed in the com dll
*--The above is like it is only running the code in the procs below and not the built-in code in the dll

*--To create the class in vfp, I dragged/dropped the interface from the object explorer
*--Note this was _aclass originally and I tested renaming it throughout to aClass to no avail
DEFINE CLASS aClass AS session OLEPUBLIC

	IMPLEMENTS aClass IN "a.CachStandardAPI.tlb"
	PROCEDURE aClass_Connect(Port AS Number) AS Number
        ? [in aClass_Connect]                     && <--This fires
	* add user code here
	ENDPROC

	PROCEDURE aClass_Connect_2(RemoteMachine AS STRING, Port AS Number) AS Number
	* add user code here
	ENDPROC

	PROCEDURE aClass_SetAVals(obj AS VARIANT) AS Number
		DODEFAULT()                        
		=MESSAGEBOX('in aSetVals Event')    && <--This fires
	* add user code here
	ENDPROC
ENDDEFINE && etc, more procedures exist above and all can be trapped

Now a question on the above code. Not sure I get it.

In the object browser I see the classes, methods, props, and interfaces of the com dll.

I see this class: 'aClass'
I see this interface: '_aClass'
I see no events (lightening bolts under events - events shows 0).
If I check the interface members within aClass, I see _aClass.
So that tells me that the class aClass implements the interface _aClass (right?)
Now, I cannot drag/drop the class itself into vfp, but I can drag/drop the interface _aClass and it will produce the define statement above.
When I do that, since aClass implements _aClass, if I call a method in aClass (which exists in the interface _aClass as well), and I hooked up the method to the eventhandler above, shouldn't the code above in _aclass run as well as the _aclass code in the com dll? it appears that only the code above runs, not the code in the com dll. Also, I cannot call aClass directly this way, only the interface _aClass.

If I hook it to my original code like so:

EVENTHANDLER(loAPI,x)

shouldn't calling loAPI.setaVals(loAObject) run the code above in the define statement? It does not, but it does update the com dll as it should, but the eventhandler seems to do nothing.

Also, I can call all of the methods in the interface when I use x. (they are brought into the define statement) which appear to not run code in the dll but only the code in the define statement above, but I cannot see the getAVals method using loAPI still (returns unsupported interface) which I do not understand since getAVals exists in the interface _aClass which is implemented in aClass.

Hope I explained this well enough. I am clearly not understanding this correctly.

Running the above code (using the define statements) seems to overwrite the interface behavior and not run the default interface behavior in the com dll at all. This I do not understand since I clearly get a connection number when I call the x.aClass_Connect(5000)

Note: the interface when dragged/dropped into vfp was _aclass which i tested with the same results as after I renamed it throughout to aClass (to see if it made a difference which it does not).

Also, when I look at an example solution in c#, I see overloaded methods for the connect method of aclass and one of them includes a parameter of a callback function, but those overloaded methods are not exposed via com. Only the first method with the single parameter of the port is visible via com.