Results 1 to 12 of 12

Thread: Event Handling C# to VB.Net conversion

  1. #1

    Thread Starter
    Junior Member
    Join Date
    Jul 2019
    Posts
    21

    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.

  2. #2
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    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:
    1. Public Event CueWaitPulsed As EventHandler
    2.  
    3. Protected Overridable Sub OnCueWaitPulsed(e As EventArgs)
    4.     RaiseEvent CueWaitPulsed(Me, e)
    5. 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.

  3. #3
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    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?

  4. #4

    Thread Starter
    Junior Member
    Join Date
    Jul 2019
    Posts
    21

    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.

  5. #5
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: Event Handling C# to VB.Net conversion

    Here is what I think you need in VB:
    vb.net Code:
    1. Private ReadOnly cueWaitPulsedHandlers As New List(Of EventHandler)
    2.  
    3. Public Custom Event CueWaitPulsed As EventHandler
    4.     AddHandler(value As EventHandler)
    5.         cueWaitPulsedHandlers.Add(value)
    6.     End AddHandler
    7.  
    8.     RemoveHandler(value As EventHandler)
    9.         cueWaitPulsedHandlers.Remove(value)
    10.     End RemoveHandler
    11.  
    12.     RaiseEvent(sender As Object, e As EventArgs)
    13.         For Each cueWaitPulsedHandler In cueWaitPulsedHandlers
    14.             cueWaitPulsedHandler.BeginInvoke(Me, e, Nothing, Nothing)
    15.         Next
    16.     End RaiseEvent
    17. End Event
    18.  
    19. Protected Overridable Sub OnCueWaitPulsed(e As EventArgs)
    20.     RaiseEvent CueWaitPulsed(Me, e)
    21. 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.

  6. #6

    Thread Starter
    Junior Member
    Join Date
    Jul 2019
    Posts
    21

    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?

  7. #7
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: Event Handling C# to VB.Net conversion

    Quote Originally Posted by Bensley196 View Post
    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.

  8. #8
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    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

  9. #9
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: Event Handling C# to VB.Net conversion

    Quote Originally Posted by Shaggy Hiker View Post
    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.

  10. #10
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    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

  11. #11
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    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.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  12. #12
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,989

    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
  •  



Click Here to Expand Forum to Full Width