-
Mar 10th, 2020, 02:12 AM
#1
Thread Starter
Junior Member
Event Handling C# to VB.Net conversion
Hello all,
I'm currently converting an old project i found from C# to vb.net I believe i am at the 99% mark before i can get it to run but i am having problems with the final 1% I have a few bits of code that access events in a way that VB.net does not enjoy as much as C# does. I believe it is finding all the handlers in a certain event but i am not too sure i haven't seen this before. VB.net is throwing the "'Public Event CueWaitPulsed As EventHandler' is an event, and cannot be called directly. Use a 'RaiseEvent' statement to raise an event" on the 'CueWaitPulsed.GetInvocationList()' part.
EDIT:
C#:
Code:
m_practiceSharpLogic.CueWaitPulsed += new EventHandler(PracticeSharpLogic_CueWaitPulsed);
Code:
private void RaiseEventCueWaitPulsed()
{
if (CueWaitPulsed != null)
{
// explicitly invoke each subscribed event handler *asynchronously*
foreach (EventHandler subscriber in CueWaitPulsed.GetInvocationList())
{
// Event is unidirectional - No call back (i.e. EndInvoke) needed
subscriber.BeginInvoke(this, new EventArgs(), null, subscriber);
}
}
}
VB.Net:
Code:
Public Event CueWaitPulsed As System.EventHandler
Code:
Private Sub RaiseEventCueWaitPulsed()
If CueWaitPulsedEvent IsNot Nothing Then
' explicitly invoke each subscribed event handler *asynchronously*
For Each subscriber As System.EventHandler In CueWaitPulsed.GetInvocationList()
' Event is unidirectional - No call back (i.e. EndInvoke) needed
subscriber.BeginInvoke(Me, New System.EventArgs(), Nothing, subscriber)
Next
End If
End Sub
My understanding of raising events stops at Addhandler, or at the end of a sub Handles me.something. I used a little bit of RaiseEvent but not enough to understand where to add it in. I have done a fair bit of research but found nothing that really helps in this situation.
Let me know if more information is required i'm not too sure if it is a localised problem or something that goes further back.
If anyone has any ideas or where to look would be amazing.
Thanks,
Thomas
Last edited by Bensley196; Mar 10th, 2020 at 03:59 AM.
-
Mar 10th, 2020, 02:43 AM
#2
Re: Event Handling C# to VB.Net conversion
EDIT:
I just noticed that you're trying to invoke event handlers asynchronously. That puts a different spin on things. I've never tried to do that before.
ORIGINAL:
You're doing it wrong. In VB, there's no need to loop through all the individual delegates in an event. In VB, you simply make a RaiseEvent statement and the rest happens internally. I suggest that you follow the Blog link in my signature below and check out my post on Custom Events. I provide C# and VB examples for everything and you can see the differences between the two languages from that. In short, your code should probably look like this:
vb.net Code:
Public Event CueWaitPulsed As EventHandler Protected Overridable Sub OnCueWaitPulsed(e As EventArgs) RaiseEvent CueWaitPulsed(Me, e) End Sub
Note that naming of the method and the declaration, i.e. prefix the event name with "On" and declare the method Protected Overridable. More on that in my blog post.
By the way, in future, if you want our help converting C# code to VB, don't you think that it would be a good idea to provide the C# code? We shouldn't have to work out what you're trying to do from code that doesn't do it.
-
Mar 10th, 2020, 02:51 AM
#3
Re: Event Handling C# to VB.Net conversion
I would still suggest that you read my blog post all the way through but, without having delved into it too far, I think that you might have to use the final technique demonstrated in order to invoke each delegate asynchronously in VB. I guess the question is whether you really need to do that. Are you going to be in a situation where you need to execute multiple handlers for the same event simultaneously?
-
Mar 10th, 2020, 04:07 AM
#4
Thread Starter
Junior Member
Re: Event Handling C# to VB.Net conversion
Thanks for the reply
The moment i started reading the answer i thought i should have added the C# equivalent in, sorry about that just slipped my mind I've updated the original question with some extra details. If you need more of the code let me know I can provide the whole project if that is easier.
The app transposes music without adjusting speed or vice versa in a realtime mode. so removing async may break it but i am not sure. But i'll give it a go and see what happens.
-
Mar 10th, 2020, 06:36 AM
#5
Re: Event Handling C# to VB.Net conversion
Here is what I think you need in VB:
vb.net Code:
Private ReadOnly cueWaitPulsedHandlers As New List(Of EventHandler) Public Custom Event CueWaitPulsed As EventHandler AddHandler(value As EventHandler) cueWaitPulsedHandlers.Add(value) End AddHandler RemoveHandler(value As EventHandler) cueWaitPulsedHandlers.Remove(value) End RemoveHandler RaiseEvent(sender As Object, e As EventArgs) For Each cueWaitPulsedHandler In cueWaitPulsedHandlers cueWaitPulsedHandler.BeginInvoke(Me, e, Nothing, Nothing) Next End RaiseEvent End Event Protected Overridable Sub OnCueWaitPulsed(e As EventArgs) RaiseEvent CueWaitPulsed(Me, e) End Sub
Notice that the method that raises the event still just uses a single RaiseEvent statement, while the loop that invokes each handler asynchronously is inside the RaiseEvent method of the custom event.
-
Mar 10th, 2020, 07:20 AM
#6
Thread Starter
Junior Member
Re: Event Handling C# to VB.Net conversion
Looks promising, I have a bug that i can't seem to figure out so i can't load the program to test if it works "obj\x86\Debug\Resources.resources" it's the last error in my list and i have no idea how to get rid of it. I've seen things about having duplicate .resx files and i have waded through it all and can't see any duplicates or poor rename errors. any ideas?
-
Mar 10th, 2020, 07:57 AM
#7
Re: Event Handling C# to VB.Net conversion
Originally Posted by Bensley196
any ideas?
Nothing to do with the topic of this thread. New topic = new thread, with all and only the information relevant to that topic.
-
Mar 10th, 2020, 09:50 AM
#8
Re: Event Handling C# to VB.Net conversion
What's the point of raising events asynchronously. That seems to be mostly a bad idea, to me. Raising on a different thread makes sense, but asynchronous raising seems to only make sense if you were relying on the order of event handlers handling the event, which is a race condition in the making, as far as I can see. So, what do you gain by doing that?
My usual boring signature: Nothing
-
Mar 10th, 2020, 08:58 PM
#9
Re: Event Handling C# to VB.Net conversion
Originally Posted by Shaggy Hiker
asynchronous raising seems to only make sense if you were relying on the order of event handlers handling the event
I would say the exact opposite. If you have multiple subscribers for an event and they all read the same data but don't write anything common then invoking asynchronous handlers means getting all those handlers in and out more quickly. For an event that is raised often, that may be important because, otherwise, you may end up with a backlog of event handlers all queued on the one thread. Other than that, I wouldn't think that there'd be any advantage.
-
Mar 11th, 2020, 09:57 AM
#10
Re: Event Handling C# to VB.Net conversion
What I meant by that is that the normal situation is that each event handler is called in turn, and generally people don't care about the order. You can figure out the order, but you shouldn't rely on it, because changing the order is easy enough to do that it can happen by accident as often as intent. Still, once the order is set, it doesn't change arbitrarily, but only for a reason.
Asynchronous events don't seem to offer any advantage of their own, but they DO change the order in which the event handlers will be called. So, if that's the only difference, it seems like the order of calls is important.
If it's a matter of getting in and out more quickly, then I'd say there are better ways to handle it than asynchronous. If any one handler is such a burden as to matter, then some kind of threading for the handlers seems more appropriate. For example, I had a system that received UDP messages. The handler(s) for those messages might take too much time. Therefore, one thread received the messages and stuck them onto a queue. The queue could raise an event on the UI thread, or a thread could poll for items on the queue.
My usual boring signature: Nothing
-
Mar 18th, 2020, 01:57 PM
#11
Re: Event Handling C# to VB.Net conversion
I tend to opt for event driven designs in my own code to be asynchronous because it just simplifies things more often than not. I've found myself in trouble more than once because of event handlers locking up the code that raises it. If you have some kind of loop that periodically reports through events, I find it's best not to tie up that loop by having it wait for event handlers to return. Most times, the object raising the event doesn't care what happens in the event handler so why wait for it to finish. It's better to raise it asynchronously and move on. Of course this is not true always but it will be most times.
-
Mar 18th, 2020, 04:00 PM
#12
Re: Event Handling C# to VB.Net conversion
I suppose I would choose to be more explicitly threaded, in that scenario. I realize that my view is based on the perpetually asynchronous JavaScript, which can cause real nightmares in some situations, so I may well be overly untrusting when it comes to asychronisity, but that's the way it is for me.
My usual boring signature: Nothing
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|