VFP, .Net and COM

[VolkerStamme]

Hi,
I'm currently experiencing a problem with the COM events interface. The server is written in C# and the client in VFP using the EventHandler() function. Works fine, no problem. The problem is that after I've used EventHandler() (whether that event ever happened or not) VFP will crash on exiting. I.e. so far the application WOULD run fine and do everything it's supposed to do but as soon as I quit VFP I run into a C005. If I don't use EventHandler() and just deal with the other elements of the server it's fine. I've tested the OLEDB example in the help files, runs fine. I've also tested the .Net server with a C++ client and a VB6 client - fine. It seems to be that one constellation, COM server in .net and client in VFP, that doesn't work properly. Tested with VFP 8 and 9. Any ideas?

 

[Olaf Doschke]

Hi Volker,

it seems the EventHandler still runs when the COM server get's destroyed and VFPs object reference "police" doesn't like that. Is there some method to stop the EventHandler beforehand?

Bye, Olaf.

 

[VolkerStamme]

Is there some method to stop the EventHandler beforehand?

Sure, calling EventHandler again with the Disconnect-flag. That's what I'm doing. Here's the code:

LOCAL	loServer as DotNetEventServer.DotNetEventSender
LOCAL loHandler

ASSERT .f.
loHandler = CreateObject( "CHandler" )
loServer = CreateObject( "DotNetEventServer.DotNetEventSender" )

EventHandler( loServer, loHandler )
loServer.FireTheEvent()
EventHandler( loServer, loHandler, .T. )

CLEAR ALL

DEFINE CLASS CHandler AS session

	IMPLEMENTS _DEventInterface IN DotNetEventServer.DotNetEventSender

	PROCEDURE _DEventInterface_TheEvent ( msg as String )	
		MessageBox( msg )
	ENDPROC

ENDDEFINE

And as I said, it doesn't make any difference whether the event actually fires or not. As soon as I take the two "EventHandler()" out it's fine. For those who are interested, here's the C# code (Taken from a book but my own code was similar and crashed as well).

using System;
using System.Runtime.InteropServices;

namespace DotNetEventServer
{
	// This is the name of the event interface to be
	// generated.
	[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
	[Guid("3289316F-0B19-44f1-B33B-8673D6FAF057")]
	public interface _DEventInterface
	{
		[DispId(1)]void TheEvent(string msg);
	}

	// The DotNetEventSender .NET class defines
	// _DEventInterface as the [default, source].
	[ComSourceInterfaces(typeof(_DEventInterface))]
	[ClassInterface(ClassInterfaceType.AutoDual)]
	[Guid("24F279CB-D9BA-4ca4-95CD-2F2338443088")]
	public class DotNetEventSender 
	{
		public DotNetEventSender(){}

		// No need to show this delegate to COM
		[ComVisible(false)]
		public delegate void MyEventTarget(string msg);

		public event MyEventTarget TheEvent;

		public void test()
		{}
		public void Clear()
		{
			TheEvent = null;
		}
		public void FireTheEvent()
		{
			if ( TheEvent != null )
				TheEvent("Hello from the DotNetEventSender");
		}

	}
}

Thanks,

Volker/

 

[Olaf Doschke]

An example that worked for me regarding IMPLEMENTS and EVENTHANDLER() is this one:

http://support.microsoft.com/?kbid=305471,

or the one about the ADODB.Recordset in the VFP help topic on Eventhandler().

I wonder if you can learn from that, as you can't have insight in the Agent DLL (agentctl.dll) or the adodb.recordset comserver, but you may find out rough similarities or differences between that DLLs (which obviously work) and your C# "DotNetEventServer.DotNetEventSender" DLL with VFPs object browser.

Maybe the reason, why it doesn't work is the way System.Runtime.InteropServices creates a COM wrapper around the C# assembly. Help on Eventhandler says oComobject must be a "valid" COM object. That isn't very clear.

You may investigate a little further with terms like IDispatch, vTable, IConnectionPoint, COM+ etc. I'm not really a pro in this subject, but you may be able to get an idea, what could help.

Bye, Olaf.

 

[VolkerStamme]

That's the example I mentioned. Works fine. But so does my COM server with any other client but VFP...

Volker/