Monthly Archives: August 2004

Back from the beach…

Things have been quiet around Panopticon Central while Andrea and I headed out to the East Coast to hang out at the North Carolina beach with my family and in Virginia with her family. We managed to get good weather all around, managing to avoid hurricane related storms and the like. So now I’ve got a few things to catch up on – after roughly a day of work, I’ve got my email down to under 100 messages, which is good but not perfect (I try to keep my Inbox at least under 20).

And Scott, before we add “ain’t” to VB, we’re at least going to add “y’all” as a statement separator. As in:

If x < 10 Then Y’all
    Return 30 Y’all
End If Y’all

I guess for the Canadians, we’ll also need to accept “eh?” as a statement separator as well…

Nice words for My…

Jesse Liberty has written a very nice article on My for O’Reilly’s OnDotnet.com. He starts with a theme we’ve seen a lot of over the years:

For a couple of years now, I’ve been touting the Microsoft-endorsed sentiment that it really doesn’t matter if you program in C# or in VB.NET, since both are just syntactic sugar layered on top of MSIL (Microsoft Intermediate Language, the true language of .NET).

But then adds:

That appears to be changing a bit with Whidbey.

He then talks about some of the features you’ll get with My. He concludes with:

The My object has made creating this application almost absurdly easy. [...] VB 2 has taken a dramatic lead in Rapid Application Development with the My object.

Go check it out!

Custom events

In my previous entry on events (written well before even VS 2002 had shipped), I made the comment:

VB does not have a syntax for defining events that allows you to specify the field, the add method or the remove method. Those are always implicitly generated.

Now, most of the time this doesn’t really matter. Most of the time, the code you write in the add and remove method is going to be the same boilerplate code over and over and over again, so you’re going to want to just let the compiler do its thing and not worry about it too much. However, there are some situations in which you might want to take over managing an event’s delegate. The most common case that I know of is the situation in which you have an object that raises a lot of events. For example, a Form can raise something like 85 different events. If you accept the default compiler behavior, this means that the compiler will generate a field for each and every event to store the event handlers for that event. Which means in the case of Form, that it would generate something like 85 fields, even though in most cases programmers only ever handle about 4-5 events on a Form!

One alternative to wasting all that space is to use a hashtable to store delegates for just the events that someone is handling. To do this, though, you need to be able to control what happens when someone hooks up to or unhooks from an event. So, in VB 2005, we’re introducing something we call custom events that look something like this:

Class C1
    Public Custom Event MyEvent As EventHandler
        AddHandler(ByVal d As EventHandler)
            …
        End AddHandler

        RemoveHandler(ByVal d As EventHandler)
           …
        End RemoveHandler

        RaiseEvent(ByVal o As Sender, ByVal e As EventArgs)
            …
        End RaiseEvent
    End Event
End Class

Custom events are declared with the Custom modified on the event declaration and have to explicitly state their delegate type. Custom events have three parts: an AddHandler method that is called when someone is hooking up to the event, a RemoveHandler method that is called when someone unhooks from the event and a RaiseEvent method that is called when the class does a RaiseEvent on the event. The AddHandler and RemoveHandler methods take a delegate of the type of the event. The RaiseEvent method takes the same parameters as the event delegate does. So, to store all event delegates in one hashtable, you could do the following:

Class C1
    Private EventDelegates As New Dictionary(Of String, EventHandler)

    Private Sub AddNewHandler(ByVal eventName As String, ByVal handler As EventHandler)
        If EventDelegates.ContainsKey(eventName) Then
            EventDelegates(eventName) = CType([Delegate].Combine(EventDelegates(eventName), handler), EventHandler)
        Else
            EventDelegates(eventName) = handler
        End If
    End Sub

    Private Sub RemoveExistingHandler(ByVal eventName As String, ByVal handler As EventHandler)
        If EventDelegates.ContainsKey(eventName) Then
            EventDelegates(eventName) = CType([Delegate].Remove(EventDelegates(eventName), handler), EventHandler)
        End If
    End Sub

    Private Sub RaiseOneEvent(ByVal eventName As String, ByVal sender As Object, ByVal e As EventArgs)
        If EventDelegates.ContainsKey(eventName) Then
            Dim p As EventHandler = EventDelegates(eventName)

            If p IsNot Nothing Then
                p.Invoke(sender, e)
            End If
        End If
    End Sub

    Public Custom Event MyEvent As EventHandler
        AddHandler(ByVal d As EventHandler)
            AddNewHandler(“MyEvent”, d)
        End AddHandler

        RemoveHandler(ByVal d As EventHandler)
            RemoveExistingHandler(“MyEvent”, d)
        End RemoveHandler

        RaiseEvent(ByVal sender As Object, ByVal e As EventArgs)
            RaiseOneEvent(“MyEvent”, sender, e)
        End RaiseEvent
    End Event
End Class

One thing to notice that’s different from C# is that we make you specify a RaiseEvent method. This is to enable the RaiseEvent statement, which C# doesn’t have, to work properly. Otherwise, it works pretty much the same way C#’s event declaration does.

More upcoming chats

The VB team blog has listed the upcoming team chats, but I thought I’d also put in a word for one I’m going to be participating in. Also, if there are any topics that you’d like to see, just leave a comment and I’ll pass it along!

Visual Basic 2005 Language Enhancements
Visual Basic 2005 has many new and improved language features, including generic types, operator overloading, compiler warnings, partial classes, mixed access properties, unsigned data types, and more. Join members of the Visual Basic team to discuss these features. Provide the team with your feedback about the Beta version and get answers to your questions.

August 12, 2004
1:00 – 2:00 P.M. Pacific time
4:00 – 5:00 P.M. Eastern time
20:00 – 21:00 GMT
OutlookAdd to Outlook Calendar
FriendTell a Friend