Assign a method to a variable

This code isn't working, and I didn't expect it to. I'm using it to try and describe what I'm trying to do. I would like to store a method as one would store a variable. Is this possible? Is it bad practice?

Code:

---

    Private Delegate Sub ParseMethod(segment As String)
    Private Sub Parse(x12 As String, delimiter As Char)

        For Each segment In x12.Split(delimiter)
            Select Case segment.Substring(0, 2)
                Case "HL"
                    ParseMethod = AddressOf ParseHl
                Case "CL"
                    ParseMethod = AddressOf ParseCL
                Case "SV"
                    ParseMethod = AddressOf ParseSV
                Case Else
                    ParseMethod(segment)
            End Select
        Next
    End Sub

    Private Sub ParseHl(segment As String)

    End Sub

    Private Sub ParseCL(segment As String)

    End Sub

    Private Sub ParseSV(segment As String)

    End Sub

---

Looks like I was close, but I'm still curious if this is the best way, or considered bad practice.

Code:

---

    Private Delegate Sub ParseMethod(segment As String)
    Private Sub Parse(x12 As String, delimiter As Char)
        Dim pm As ParseMethod
        For Each segment In x12.Split(delimiter)
            Select Case segment.Substring(0, 2)
                Case "HL"
                    pm = AddressOf ParseHl
                Case "CL"
                    pm = AddressOf ParseCL
                Case "SV"
                    pm = AddressOf ParseSV
                Case Else
                    pm(segment)
            End Select
        Next
    End Sub

    Private Sub ParseHl(segment As String)

    End Sub

    Private Sub ParseCL(segment As String)

    End Sub

    Private Sub ParseSV(segment As String)

    End Sub

---

i dont think there is anything wrong with this approach. if its the best way is probably depending on the data you are dealing with, but yes you are using delegates correctly.

depends on what the format of x12 is... if it looks something like HL12 SV7 SV8 ... you'll run into issues...
as it loops, it'll see HL12 ... taking the first two of that, it sees HL, created the reference to ParseHL ... but then the next loop it'll see SV7... so the pm variable gets rereferenced to ParseSV ... it won't slip into the else case at all.
if the string is HL 12 SV 7 SV 7 ... then yes it might work.

-tg

What advantage does that have over calling your sub routines directly?

Code:

---

  Private Sub Parse2(x12 As String, delimiter As Char)
    Dim segments() As String = x12.Split(delimiter)

    For Each segment In segments
      Dim Prefix As String = segment.Substring(0, 2)
      Select Case Prefix
        Case "HL"
          ParseHl(segment)
        Case "CL"
          ParseCL(segment)
        Case "SV"
          ParseSV(segment)
      End Select
    Next
  End Sub

  Private Sub ParseHl(segment As String)

  End Sub

  Private Sub ParseCL(segment As String)

  End Sub

  Private Sub ParseSV(segment As String)

  End Sub

---

I'm not being snide I really do not understand delegates.

In this case, it's simplistic, so it may not make sense... I'm assuming it's a bit more complicated than this.

As for delegates, you use them all the time... Event Handlers... are a form of delegates. In short they are pointers to a function that conforms to a given delegate signature.

Using wildBill's example... all three of his individual parse methods conform to the signature dictated by the Delegate at the top.

If for, example, he then declared the following:

Code:

---

Private sub ParseThis(segment as integer)

End Sub

---

He wouldn't be able to assign the AddressOf it to the pm variable... because it doesn't conform to the Delegate signature (the parameter types are incorrect.)

they can be a hard concept to wrap one's head around initially, it took me years before I truly understood them.

Back to Event handlers. Event handlers being delegates is what makes AddHandler TextBox.TextChanged, AddressOf someEventHandler possible.

Behind the scenes (and this is a very simplistic view of it) the control maintains a list of delegates for the different events. When the even is fired, it iterated through the list and calls each stored delegate. As a result you can have multiple handlers for the same event, as well as the same event handler for multiple events (as long as their delegate definition conforms).

It also makes calls possible to unknown objects. I've got a sample project around here on VBF somewhere that uses delegates to distribute messages selectively to other forms in the project. If I can find it, I'll link to it.

-tg

consider this contrived & trivial example:

Code:

---

    Private Delegate Function GetDataDelegate(SQLString As String) As DataTable

    Private GetData As GetDataDelegate

    Private Sub InitDataConnection(UseSQLServer As Boolean)
        If UseSQLServer Then
            GetData = AddressOf GetDataFromSQLServer
        Else
            GetData = AddressOf GetDataFromAccess
        End If
    End Sub

    Private Function GetDataFromAccess(SQLString As String) As DataTable
        Return New DataTable
    End Function

    Private Function GetDataFromSQLServer(SQLStrin As String) As DataTable
        Return New DataTable
    End Function

    Private Sub RetrieveUsers()
        Dim dtUsers As DataTable = GetData("Select * from Users") ' Note, I don't care if it came from SQL Server or Access... I jsut call A method...
        'And it can be expanded to support other DB types as well.
    End Sub

---

So I create a Delegate GetDataDelegate ... that defines the signature needed.
I then declare a pointer of the delegate type.
Inside the InitDataConnection method, I decide, am I connecting to Access or SQLServer and create a pointer to the appropriate method as needed.
Then in the RetrieveUsers, I simply invoke the delegate. I don't care WHICH method it points to... All I know/care about it passing it hte SQL to process, and it's going to return a datatable.

Normally this is done by crossing classes and assemblies... let's say the Access methods are in a clas AccessDB, and the SQL Server ones are in SQLServerDB ... I could do it like this:

Code:

---

    Private Delegate Function GetDataDelegate(SQLString As String) As DataTable

    Private GetData As GetDataDelegate

    Private Sub InitDataConnection(UseSQLServer As Boolean)
        If UseSQLServer Then
            GetData = AddressOf SQLServerDB.GetSQLServerData
        Else
            GetData = AddressOf AccessDB.GetAccessData
        End If
    End Sub

    Private Sub RetrieveUsers()
        Dim dtUsers As DataTable = GetData("Select * from Users") ' Note, I don't care if it came from SQL Server or Access... I jsut call A method...
        'And it can be expanded to support other DB types as well.
    End Sub

---

Yes, an interface could also work here... again this is a trivial and contrived example.

-tg