Confused by Delegate Events

[Michael Tissington]

I'm confused by documentation and examples on using Delegate to create
Events for use with COM

In some situation I see a parameter list of (sender as Object, e as
EventArgs) and other times I see no parameters, or a list of parameters that
are event dependent.

Below is my .NET code to create a class which raises some events.
From C++ (using MFC 6.0) I create an instance of the object and
IConnectionPoin tContainer which seems to work.

When the .NET object raises the event I get an exception of type

System.NullRefe renceException: Object reference not set to an instance of an
object.
at MapiForm._FormE vents.Shutdown( )
at MapiForm.MAPIFo rm.frm_ShutDown Form() in D:\My
Documents\SQLVi ew\Forms\MAPIFo rm\MAPIForm.vb: line 63
at MapiForm.Outloo kForm.txtShutdo wn_Click(Object sender, EventArgs e) in
D:\My Documents\SQLVi ew\Forms\MAPIFo rm\OutlookForm. vb:line 113
at System.Windows. Forms.Control.O nClick(EventArg s e)
at System.Windows. Forms.Button.On Click(EventArgs e)
at System.Windows. Forms.Button.On MouseUp(MouseEv entArgs mevent)
at System.Windows. Forms.Control.W mMouseUp(Messag e& m, MouseButtons
button, Int32 clicks)
at System.Windows. Forms.Control.W ndProc(Message& m)
at System.Windows. Forms.ButtonBas e.WndProc(Messa ge& m)
at System.Windows. Forms.Button.Wn dProc(Message& m)
at System.Windows. Forms.ControlNa tiveWindow.OnMe ssage(Message& m)
at System.Windows. Forms.ControlNa tiveWindow.WndP roc(Message& m)
at System.Windows. Forms.NativeWin dow.Callback(In tPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)

*************** ****

Any ideas how I need to setup events so that I can call them from MFC 6.0
???

Thanks!

*************** ***

----------- snip -------------
Imports System
Imports System.Runtime. InteropServices

<ComVisible(Fal se)> Public Delegate Sub NewMessageEvent Handler()
<ComVisible(Fal se)> Public Delegate Sub ShutdownEventHa ndler()
<ComVisible(Fal se)> Public Delegate Sub PrintEventHandl er()
<ComVisible(Fal se)> Public Delegate Sub SavedEventHandl er()

<GuidAttribute( "93D44286-4BA4-4cc7-8971-0C7831EA0354"),
InterfaceTypeAt tribute(ComInte rfaceType.Inter faceIsDual)> _
Public Interface _Form
<DispId(&H1001) > Sub ShowForm(ByVal sCN As String, ByVal sGUID As
String)
<DispId(&H1002) > Sub ShutDownForm(By Val SaveOptions As UInt32)
<DispId(&H1003) > Sub DoVerb(ByVal Verb As Int32)
End Interface

<GuidAttribute( "06670E52-A3C2-480b-8D7A-7CE3DD1D03A3"),
InterfaceTypeAt tribute(ComInte rfaceType.Inter faceIsDual)> _
Public Interface _FormEvents
<DispId(&HF001) > Sub NewMessage()
<DispId(&HF002) > Sub Shutdown()
<DispId(&HF003) > Sub Print(ByVal PageNumber As UInt32, ByVal Status As
UInt32)
<DispId(&HF004) > Sub Saved()
End Interface

' This is your COM object, you must implement _Form and _FormEvents
' For each object that you create you will need to assign a unique GUID
' and give the class a unique ProgID
<GuidAttribute( "9d8a13bf-df52-3084-954b-95e85887111d"),
ProgIdAttribute ("SQLView.Form" ), ClassInterface( ClassInterfaceT ype.None),
ComSourceInterf aces(GetType(_F ormEvents))> _
Public Class MAPIForm
Implements _Form

Public Event NewMessage As NewMessageEvent Handler
Public Event ShutDown As ShutdownEventHa ndler
Public Event Print As PrintEventHandl er
Public Event Saved As SavedEventHandl er

Private WithEvents frm As New OutlookForm

' A creatable COM class must have a Public Sub New()
' with no parameters, otherwise, the class will not be
' registered in the COM registry and cannot be created
' via CreateObject.
Public Sub New()
MyBase.New()
End Sub

Public Sub ShowForm(ByVal sCN As String, ByVal sGUID As String)
Implements _Form.ShowForm
' This is called by Outlook when a form needs to be displayed
frm.txtCON.Text = sCN
frm.txtGUID.Tex t = sGUID
frm.Show()
End Sub

Public Sub ShutDownForm(By Val SaveOptions As UInt32) Implements
_Form.ShutDownF orm
' The is called by Outlook when it wants to close the form
End Sub

Public Sub DoVerb(ByVal Verb As Int32) Implements _Form.DoVerb
' The is called by Outlook when a verb (eg Print) needs to be done
' Verbs are defined in the cfg file
End Sub

Private Sub frm_ShutDownFor m() Handles frm.ShutDownFor m
RaiseEvent ShutDown()
End Sub
End Class


-----------------------------

--
Michael Tissington

http://www.oaklodge.com

http://www.tabtag.com

[stand__sure]

Re: Confused by Delegate Events

more code is needed... it's hard to help you when you're not posting
enough code to allow a respondent to test it and get the same error. I
do realize that this is part of a commercial project, but if you want
to get help in a public forum, you'll have to divulge more -- your
previous problem that was looking at the wrong typelib being a
case-in-point (with sufficient code, someone else likely would have
found it quickly)

as an aside, why are jumping back and forth between technologies? it
would seem simpler to roll forward the parts of your app that call
legacy COM components than to write new components and force old apps
to use them...

[Michael Tissington]

Re: Confused by Delegate Events

Hmm, not sure what else I can produce in terms of code - aside from the
actual COM client.

I don't think I am jumping back and forth ...

Legacy application is written in C++ and is COM compliant and needs to talk
to a .NET component - how they talk to each other, COM, is what is being
developed.

--
Michael Tissington

http://www.oaklodge.com

http://www.tabtag.com

"stand__sur e" <stand__sure@ho tmail.com> wrote in message
news:1117776825 .247220.59950@z 14g2000cwz.goog legroups.com...[color=blue]
> more code is needed... it's hard to help you when you're not posting
> enough code to allow a respondent to test it and get the same error. I
> do realize that this is part of a commercial project, but if you want
> to get help in a public forum, you'll have to divulge more -- your
> previous problem that was looking at the wrong typelib being a
> case-in-point (with sufficient code, someone else likely would have
> found it quickly)
>
> as an aside, why are jumping back and forth between technologies? it
> would seem simpler to roll forward the parts of your app that call
> legacy COM components than to write new components and force old apps
> to use them...
>[/color]

[stand__sure]

Re: Confused by Delegate Events

enough client code to throw into the compiler would be helpful... I
often find my problems more readily when I create test stubs that work
while the original doesn't...

as for the back and forth...
I am wondering if it wouldn't be easier to roll the part that needs to
interact with the COM object forward to .NET. I realize the
(potential) enormity of updating an entire application, but it seems
like rolling the presentation layer forward would be manifestly easier
than shoe-horning a .NET COM component into a legacy application...