By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,327 Members | 1,096 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,327 IT Pros & Developers. It's quick & easy.

Confused by Delegate Events

P: n/a
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
IConnectionPointContainer which seems to work.

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

System.NullReferenceException: Object reference not set to an instance of an
object.
at MapiForm._FormEvents.Shutdown()
at MapiForm.MAPIForm.frm_ShutDownForm() in D:\My
Documents\SQLView\Forms\MAPIForm\MAPIForm.vb:line 63
at MapiForm.OutlookForm.txtShutdown_Click(Object sender, EventArgs e) in
D:\My Documents\SQLView\Forms\MAPIForm\OutlookForm.vb:li ne 113
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons
button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage (Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(M essage& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr 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(False)> Public Delegate Sub NewMessageEventHandler()
<ComVisible(False)> Public Delegate Sub ShutdownEventHandler()
<ComVisible(False)> Public Delegate Sub PrintEventHandler()
<ComVisible(False)> Public Delegate Sub SavedEventHandler()

<GuidAttribute("93D44286-4BA4-4cc7-8971-0C7831EA0354"),
InterfaceTypeAttribute(ComInterfaceType.InterfaceI sDual)> _
Public Interface _Form
<DispId(&H1001)> Sub ShowForm(ByVal sCN As String, ByVal sGUID As
String)
<DispId(&H1002)> Sub ShutDownForm(ByVal SaveOptions As UInt32)
<DispId(&H1003)> Sub DoVerb(ByVal Verb As Int32)
End Interface

<GuidAttribute("06670E52-A3C2-480b-8D7A-7CE3DD1D03A3"),
InterfaceTypeAttribute(ComInterfaceType.InterfaceI sDual)> _
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(ClassInterfaceType.None),
ComSourceInterfaces(GetType(_FormEvents))> _
Public Class MAPIForm
Implements _Form

Public Event NewMessage As NewMessageEventHandler
Public Event ShutDown As ShutdownEventHandler
Public Event Print As PrintEventHandler
Public Event Saved As SavedEventHandler

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.Text = sGUID
frm.Show()
End Sub

Public Sub ShutDownForm(ByVal SaveOptions As UInt32) Implements
_Form.ShutDownForm
' 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_ShutDownForm() Handles frm.ShutDownForm
RaiseEvent ShutDown()
End Sub
End Class
-----------------------------

--
Michael Tissington
http://www.oaklodge.com
http://www.tabtag.com

Nov 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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...

Nov 21 '05 #2

P: n/a
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__sure" <st*********@hotmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
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...

Nov 21 '05 #3

P: n/a
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...

Nov 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.