Please take a look at the code below, which works as I would expect:
Partial Class _Default
Inherits System.Web.UI.Page
Delegate Sub TestEventHandler(ByVal o As Object, ByVal e As EventArgs)
Dim alhandler As TestEventHandler = AddressOf TestEventMethod
Public Event Test1 As TestEventHandler
Public Event Test2 As TestEventHandler
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
AddHandler Me.Test1, alhandler
AddHandler Me.Test2, alhandler
RaiseEvent Test1(Me, e)
RaiseEvent Test2(Me, e)
RemoveHandler Me.Test1, alhandler
RaiseEvent Test1(Me, e)
End Sub
Public Sub TestEventMethod(ByVal o As Object, ByVal e As EventArgs)
MsgBox("Test")
End Sub
End Class
I am confused with the two statements below:
Dim alhandler As TestEventHandler = AddressOf TestEventMethod '1
Public Event Test1 As TestEventHandler '2
1) This is saying that the reference of alHandler is a delegate that
points to the address of a function. 2) This is saying that Test1 is
an event of type Delegate. How can an event and a handler be a
delegate?
As others have said, each type of delegate is a type, just as if it were a regular class. So, in your example code, TestEventHandler is a delegate type. A TestEventHandler variable can reference any TestEventHandler object, just like any other variable can reference any object of its own type. TestEventHandler objects must be instantiated, just like objects of any other type.
Delegates are special, however, in that you declare them using a different, special, syntax. For instance, if you had the following method:
Public Sub MyMethod(Text As String)
' ...
End Sub
You could create a delegate that matches that method signature like this:
Public Delegate Sub MyMethodDelegate(Text As String)
Remember, by doing so, that simply defines the MyMethodDelegate type. That doesn't declare a variable of that type nor does it instantiate an object of that type.
There are two things in VB.NET syntax, however, which often cause a lot of confusion. First, when you declare an event, you can use two different syntax:
Public Event MyEvent As MyMethodDelegate
Public Event MyEvent(Text As String)
Both of those lines do the same thing. The first line defines the event using an already defined delegate type. The second line essentially defines a new unnamed delegate on the fly and then uses it as the type for the event. (Note, I'm using the MyMethodDelegate for simplicity, and that will work, but standards dictate that events should have a sender and an event args.) When an event is declared, think of it like a variable. Behind the scenes, it's really like a collection object that keeps a list of all the delegate objects that are added to it using the AddHandler function.
The second confusing thing in VB.NET is that the compiler will automatically instantiate a new delegate object for you, if necessary, when you use the AddressOf function. So, for instance, when you do something like this:
AddHandler myObject.MyEvent, AddressOf MyMethod
It's just a shortcut for typing the full text, like this:
AddHandler myObject.MyEvent, New MyMethodDelegate(AddressOf MyMethod)
The latter, in my opinion is much more clear. What you are actually doing is creating a new object of that delegate type and pointing that delegate object to that method, and then adding that delegate object to the event (that event collection-like variable defined by the object's type).
So, in your example, this line:
Dim alhandler As TestEventHandler = AddressOf TestEventMethod
Would be more clearly written as:
Dim alhandler As TestEventHandler = New TestEventHandler(AddressOf TestEventMethod)
It's declaring a delegate variable and then setting it to a new delegate object that points to that particular method. In this case, it's just a standard delegate variable, not an event. Events are very similar to delegates field/properties. Events are essentially an accessor wrapper around a private delegate field, in the same way that properties often wrap a private field. The big differences between delegate fields and events are that events support the AddHandler and EventHandler functions and events cannot be raised/invoked from outside of the class that defines it.
Related
Given two classes with identical events I'd like to be able to refer to them using one name. Similar to the following:
Public Class myclass1
Public event1()
End Class
Public Class myclass2
Public event1()
End Class
Here I'd like to be able to determine at run time which class to use:
Sub somefunction(select as integer)
Dim voidclass
if select = 1 then
voidclass = myclass1
else
voidclass = myclass2
end if
AddHandler voidclass.event1, AddressOf eventhappened
End Sub
Sub eventhappened()
msgbox("Event occured")
End Sub
Obviously there may be a better method for this example, but let's assume that class book1 already exists, and that I'm tasked with creating book2 and only modifying somefunction without modifying book1 itself.
The example above should result in the error event1 is not an event of 'Object'`.
It appears that properties and methods are fine with this, but events are not. How do I handle events in this situation?
The snippet does not match the question very well. It has an odd bug, the events in the classes are not declared Shared so the code must use a proper object reference. Not a type name. Maybe the answer is as simple as:
Private obj1 As myclass1
Private obj2 As myclass2
Sub somefunction(select as integer)
If select = 1 Then
AddHandler obj1.event1, AddressOf eventhappened
Else
AddHandler obj2.event1, AddressOf eventhappened
End If
End Sub
But presumably the real question is the same scenario, but now the variables declared as:
Private obj1, obj2
Untyped and thus Object. Yes, VB.NET does not support that. As with most quirks in VB.NET there is history behind this. VB never did support explicit late binding of events, only methods and properties. The scheme in the legacy versions was very quirky. You had to declare the variable with the WithEvents keyword and pick a specific name for the event handler. In other words:
Dim WithEvents obj1
Sub obj1_somethinghappened
'' handles the event1 event for obj1
End Sub
Or to put it another way, all events were late-bound. This scheme was not carried forward into VB.NET, too many practical problems with it. WithEvents still survives but now requires the Handles keyword on the method declaration. That doesn't do what you want it to do.
The VB.NET designers intentionally did not add late binding support to the AddHandler statement. I am not privy to the exact reason they decided this and can only guess. There is no technical reason it could not be added, it just requires the compiler to generate reflection code. One possible explanation is that they considered it too expensive. Another is that they deemed the runtime exceptions that are raised when there's a method signature mismatch too hard to interpret. I like that last one best, they are awfully ugly.
You'll have to use Reflection to get what you want. Use obj1.GetType().GetEvent("event1") to get the EventInfo, its Get/AddMethod() to add the event handler.
Fwiw, the C# language does support this in its dynamic keyword implementation. Maybe you can put a bug in their ear by asking for the feature. No real idea if this was requested before.
You can define an interface for the event and implement it in the classes then you can subscribe to this event through the interface reference. See below:
Public Interface INotifier
Event SomethingHappened()
End Interface
Public Class Class1
Implements INotifier
Public Event SomethingHappened() Implements INotifier.SomethingHappened
End Class
Public Class Class2
Implements INotifier
Public Event SomethingHappened() Implements INotifier.SomethingHappened
End Class
Module Module1
Dim notifiers As List(Of INotifier) = New List(Of INotifier) From
{
New Class1(),
New Class2()
}
Sub Main()
SubscribeToEventHandler(0)
End Sub
Private Sub SubscribeToEventHandler(ByVal index As Integer)
Dim notifier As INotifier = notifiers(index)
AddHandler notifier.SomethingHappened, AddressOf EventHandler
End Sub
Private Sub EventHandler()
End Sub
End Module
Update: I think it has something to do with lazy instantiation of the window handle for MainForm - but haven't been able to work out quite how that would result in the behavior seen here.
The application requests data via 3rd party COM interface providing a callback to process the results. In the callback, the UI needs to be updated - but the update doesn't work as expected. It's as if a value copy of MainForm had been created, when MainForm.DataReady is called or invoked directly cross thread, but UI update works as expected when executed from an event handler. Can you explain why?
(Note: AppDomain.CurrentDomain.Id is always 1 whether examined in MainForm or in ClassB.)
Initial Code - call to DataReady from ClassB instance without InvokeRequred /Delegate /Invoke logic in MainForm. Application UI change works as expected, MainForm SomeListControl.EmptyListMsg = "Not Available" change doesn't 'stick' (as if applied to a separate copy of MainForm)
Module AppGlobals
Public WithEvents A As ClassA
End Module
Partial Friend Class MyApplication
Private Sub MyApplication_Startup(ByVal sender As Object,
ByVal e As StartupEventArgs) Handles Me.Startup
A = New ClassA()
End Sub
End Class
Class MainForm
private sub getData
ToggleWait(True)
SomeListControl.Clear()
A.getData() 'Sets up the com object & callback
end sub
Public Sub DataReady()
ToggleWait(False)
' Do something with the data
End Sub
Private Sub ToggleWait(toggle as Boolean)
Application.UseWaitCursor = False
if toggle then
SomeListControl.EmptyListMsg = "Not Available"
else
SomeListControl.EmptyListMsg = "Please Wait"
end if
End Sub
End Class
Class ClassA
public sub getData()
Dim ComObj as New ComObject
Call ComObj.setClient(New ClassB)
End Sub
End Class
Class ClassB
Implements IComObjectClient
sub getdata_callback(results() as Object) handles IComObjectClient.getdata_callback
' Get the results
MainForm.DataReady()
end sub
End Class
Added InvokeRequred logic to DataReady, still called directly from ClassB. InvokeRequired is never true, Application UI change works as expected, MainForm SomeListControl.EmptyListMsg = "Not Available" change doesn't 'stick' (as if applied to a separate copy of MainForm)
Class MainForm
Public Delegate Sub DataReadyDelegate(ByVal toggle As Boolean)
...
Public Sub DataReady()
If InvokeRequired Then
Invoke(New DataReadyDelegate()
Else
ToggleWait(False)
' Do something with the data
End If
End Sub
...
End Class
Invoked MainForm.DataReady directly from ClassB Got exception: "Invoke or BeginInvoke cannot be called on a control until the window handle has been created." until I forced the window handle creation. Then it's the same behavior as before, namely, InvokeRequired is never true, Application UI change works as expected, MainForm SomeListControl.EmptyListMsg = "Not Available" change doesn't 'stick' (as if applied to a separate copy of MainForm)
Class ClassB
Implements IComObjectClient
Public Delegate Sub DataReadDelegate()
sub getdata_callback(results() as Object) handles IComObjectClient.getdata_callback
' Get the results
If Not MainForm.IsHandleCreated Then
' This call forces creation of the control's handle
Dim handle As IntPtr = MainForm.Handle
End If
MainForm.Invoke(New DataReadyDelegate(AddressOf MainForm.DataReady))
end sub
End Class
Executed from Event Handler Defined custom 'got data' events in ClassA and ClassB. ClassA listens for ClassB.got_data_event and raises ClassA.got_data_event, MainForm listens for ClassA.got_data_event and handles it by calling DataReady(). This works - InvokeRequired is true, Invoke is excuted, Application UI and MainForm UI changes work as intended.
Class MainForm
Public Delegate Sub DataReadyDelegate()
...
Public Sub DataReady()
If InvokeRequired Then
Invoke(New DataReadyDelegate()
Else
ToggleWait(False)
' Do something with the data
End If
End Sub
Public Sub _GotData_HandleEvent(ByVal resultMessage As String)
DataReady()
End Sub
Private Sub MainForm_Load(sender As Object, e As EventArgs) Handles Me.Load
...
ToggleWait(False)
AddHandler A.GotData, AddressOf _GotData_HandleEvent
...
End Sub
...
End Class
Contrast:
A.getData()
with:
If Not MainForm.IsHandleCreated Then
You are using proper object-oriented programming syntax in the first statement. A is an object. The Form.IsHandleCreated property is an instance property, it requires an object name at the left side. You however used a type name. MainForm is not an object, it is a type in your code.
That this is possible is a very nasty VB.NET feature. It exists to help VB6 programmers move to VB.NET coding, VB6 strongly encouraged using the form's type name. Syntax inherited from VB1 before VB4 implemented anything resembling objects.
Now this is most certainly a convenience. You can refer to the form object in another class by simply using the type name. Note how you did not have that convenience with the A object. You solved it by making it a global variable, storing it in a Module. That doesn't win any prices either, but did allow you to reference A in any class.
Problem is, this convenience turns deadly when you start using the fake form object in another thread. What you didn't count on is that this object has <ThreadLocal> scope. In other words, when you use it in a worker thread then you get a new object of class MainForm. This form object is not visible, you never called its Show() method. Not that this would work, the thread does not pump a message loop so that form won't paint itself properly. Another side effect you observed is that its InvokeRequired property doesn't behave. It returns False. Correctly so, the form was created on the work thread so you don't actually have to use BeginInvoke(). Not that this would work either, it is still the wrong object, not the one that the user is looking at.
So one Q&D workaround is to do the same thing with the form object as you did with the A object, store it in a global variable:
Module AppGlobals
Public WithEvents A As ClassA
Public MainWindow As MainForm
End Module
And initialize it from the class constructor:
Class MainForm
Sub New()
InitializeComponent()
MainWindow = Me
End Sub
'' etc..
End Class
Now you can refer to MainWindow in your classes. And you get a reference to the actual instance of MainForm class that the user is looking at. And get the proper return value from MainWindow.InvokeRequired.
This will solve your problem, but it is still ugly and error prone. The right way looks like this:
Public Class MainForm
Private Shared MainWindow As MainForm
Public Shared ReadOnly Property Instance() As MainForm
Get
'' Return a reference to the one-and-only instance of MainForm
If MainWindow Is Nothing Then
'' It doesn't exist yet so create an instance
'' Creating one on a worker thread will never work, so complain
If System.Threading.Thread.CurrentThread.GetApartmentState() <> Threading.ApartmentState.STA Then
Throw New InvalidOperationException("Cannot create a window on a worker thread")
End If
New MainForm()
End If
Return MainWindow
End Get
End Property
Protected Overrides Sub OnFormClosed(ByVal e As System.Windows.Forms.FormClosedEventArgs)
'' Ensure that the one-and-only instance is now Nothing since it closed
MyBase.OnFormClosed(e)
MainWindow = Nothing
End Sub
Sub New()
'' Creating more than once instance of this form can't work, so complain
If MainWindow IsNot Nothing Then Throw New InvalidOperationException("Cannot create more than one instance of the main window")
InitializeComponent()
'' We need to keep track of this instance since the Instance property returns it
MainWindow = Me
End Sub
'' etc...
End Class
Now you can use MainForm.Instance anywhere in your classes, like MainForm.Instance.InvokeRequired. And you'll be reminded when you get it wrong with an exception.
I have a two windows forms classes, a base class and a derived class. The base class has an event handler which handles ValueChanged on some component. I have also written a different event handler for the same event on the derived class.
When I create an instance of the derived class and fire the event, I find that both event handlers run (the base class one and then the derived class one). But I want only the handler in the derived class to run.
Is this possible and if so how do I do it?
(This is .NET 3.5)
Thanks!
Edit: Here is what the code looks like (can't post the actual code):
Public Class BaseForm
Inherits System.Windows.Forms.UserControl
(Windows Form Designer Generated Code)
Private WithEvents myControl As New SomeOtherControl
Protected value As String
Private Sub myControl_ValueChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles myControl.ValueChanged
value = SomeLogic()
End Sub
End Class
Public Class DerivedForm
Inherits BaseForm
Private WithEvents myControl As New SomeOtherControl
Private Sub myControl_ValueChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles myControl.ValueChanged
value = myControl.Value
End Sub
End Class
You can attach multiple handlers to one event so what you are seeing is by design (you have two handlers attached to the same event so they both fire).
That being said there are ways to accomplish what you are trying to do. One way is to move the code out of your base class handler into an overridable method, and then in the derived class override the method. So your base class handler only has 1 line of code,calling the new method you made. If you inherit from the class it will call your overridden method instead.
Public Class BaseForm
Private Sub myControl_ValueChanged() Handles myControl.ValueChanged
DoSomeLogic()
End Sub
Protected Overridable Sub DoSomeLogic()
'original logic here
End Sub
End Class
Public Class ChildForm
Inherits BaseForm
Protected Overrides Sub DoSomeLogic()
'other logic here
End Sub
End Class
I don't believe you can control that.
If it were me, I think I'd intercept the event in the base class, as you are doing, then define ANOTHER event from the base class and raise that event FROM the event handler in the base class.
on return, if the event was handled (presumably by your derived class), then just exit the base event handler, otherwise, proceed with the base event handling.
How can I put AddressOf, from another class?
I get this error 'AddressOf' operand must be the name of a method (without parentheses). "
Is there an Eval () function in VB.NET? Or how does one do this?
Public Shared Property e As UserControl
Public Shared Sub SetButton(ByVal button As String, ByVal Objekt As [Delegate])
Dim errorbuttom1 As Button = e.FindName("errorButton1")
AddHandler errorbuttom1.Click, AddressOf Objekt
End Sub
You have to have an instance of Objekt, and the method that's the delegate must be public and match the signature of the delegate. Or, the method must be public static.
I believe that would work...
I have some VB6 code that instantiates a class which handles events that are being raised from a VB.NET component. The VB6 is pretty straightforward:
private m_eventHandler as new Collection
...
public sub InitSomething()
dim handler as EventHandler
set handler = new EventHandler
m_eventHandler.Add handler
...
m_engine.Start
end sub
Note that the event handler object has to live beyond the scope of the init method (which is why it is being stored in a Collection). Note also that m_engine.Start indicates the point in the program where the VB.NET component would start raising events.
The actual event handler (as requested):
Private WithEvents m_SomeClass As SomeClass
Private m_object as Object
...
Private Sub m_SomeClass_SomeEvent(obj As Variant)
Set obj = m_object
End Sub
Note that m_object is initialized when an instance of EventHandler is created.
The VB.NET code which raises the event is even simpler:
Public ReadOnly Property SomeProp() As Object
Get
Dim obj As Object
obj = Nothing
RaiseEvent SomeEvent(obj)
SomeProp = obj
End Get
End Property
My problem is that when I debug the VB6 program, the first time InitSomething gets called, the event will not be handled (the VB6 event handler is never entered). Subsequent calls to InitSomething does work.
Everything works as I would have expected when I run the program outside the debugger. At this point, I'm not even sure if this is something I should be worried about.
It may or may not be relevant but the VB.NET was converted from a VB6 using the Visual Studio code conversion tool (and subsequently manually cleaned up).
I've found that if you are writing .Net Components for Consumption in VB6 (or any other COM environment) the utilisation of Interfaces is absolutely criticial.
The COM templates that comes out of the box with VStudio leave a lot to be desired especially when you are trying to get Events to work.
Here's what I've used.
Imports System.Runtime.InteropServices
Imports System.ComponentModel
<InterfaceType(ComInterfaceType.InterfaceIsDual), Guid(ClientAction.InterfaceId)> Public Interface IClientAction
<DispId(1), Description("Make the system raise the event")> sub SendMessage(ByVal theMessage As String)
End Interface
<InterfaceType(ComInterfaceType.InterfaceIsIDispatch), Guid(ClientAction.EventsId)> Public Interface IClientActionEvents
<DispId(1)> Sub TestEvent(ByVal sender As Object, ByVal e As PacketArrivedEventArgs)
End Interface
<ComSourceInterfaces(GetType(IClientActionEvents)), Guid(ClientAction.ClassId), ClassInterface(ClassInterfaceType.None)> _
Public Class ClientAction
Implements IClientAction
Public Delegate Sub TestEventDelegate(ByVal sender As Object, ByVal e As PacketArrivedEventArgs)
Public Event TestEvent As TestEventDelegate
public sub New()
//Init etc
end sub
public sub SendMessage(theMessage as string) implements IClientAction.SendMessage
onSendMessage(theMessage)
end sub
Protected Sub onSendMessage(message as string)
If mRaiseEvents Then
RaiseEvent TestEvent(Me, New PacketArrivedEventArgs(theMessage))
End If
End Sub
end Class
I've been able to get COM and .Net consumers of the Assembly/Component to work properly with events and be able to debug in and out of the component.
Hope this helps.
Just something to try - I have an inherent distrust of "As New .."
Can you try
private m_eventHandler as Collection
public sub InitSomething()
dim handler as EventHandler
set handler = new EventHandler
If m_eventHandler Is Nothing Then
Set m_eventHandler = New Collection
End if
m_eventHandler.Add handler
...
m_engine.Start
end sub
Alas, I've got no idea why this works in normal execution and not in debug except some vague suspicions that it's to do with .NET being unable to instantiate the VBA.Collection object (MS recommends that you write a quick VB6 component to do so), but since you're not creating collections in .NET code, it is still just a vague suspicion.