[RESOLVED] Problems with Action Delegates

[Pradeep1210]

I have a form with a button and the following code:

Public Class Form1
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim dt As New DataTable
        dt.Columns.Add("CustomerId", GetType(Integer))
        dt.Columns.Add("Rate", GetType(Integer))
        For i = 0 To 9
            dt.Rows.Add(i, 0)
        Next
 
        Dim dataRows = dt.Rows.Cast(Of DataRow)().ToList
        dataRows.ForEach(AddressOf SetRate)                 '<-- this works
        ' dataRows.ForEach(Function(dr) dr("Rate") = 9999)    '<-- this doesn't work!
        For Each dr In dt.Rows
            Console.WriteLine(dr("CustomerId") & "     " & dr("Rate"))
        Next
    End Sub
 
    Sub SetRate(ByVal dr As DataRow)
        dr("Rate") = 9999
    End Sub
End Class

Output in when I do: dataRows.ForEach(AddressOf SetRate)

0     9999
1     9999
2     9999
3     9999
4     9999
5     9999
6     9999
7     9999
8     9999
9     9999

Output when I do: dataRows.ForEach(Function(dr) dr("Rate") = 9999)

0     0
1     0
2     0
3     0
4     0
5     0
6     0
7     0
8     0
9     0

I was assuming both the codes are equivalents, but they don't seem to be so. Though there are no compilation errors, the inline-function way doesn't work.
Anyone knows the reason why? Is it because the lambda expressions are evaluated when they are first used? Or is there any other reason?

[jmcilhinney]

Um, that second code snippet is not doing anything like what you think it is. I think that you need to brush up on how lambdas work; especially the difference between action lambdas (which do not exist in VB 2008) and value lambdas. A lambda is a contraction of a conventional method. This lambda:

Function(dr) dr("Rate") = 9999

is equivalent to this conventional method:

Private Function Method(ByVal dr As DataRow) As Boolean
    Return dr("Rate") = 9999
End Function

Your code is not setting anything. It's determining whether a field is equal to a particular value.

If you take nothing else from this, turn Option Strict On right now and never turn it Off again unless you explicitly need late-binding for Office Automation or the like and, even then, only do so in partial classes where it's absolutely required. Your code wouldn;t even compile with Option Strict On and that would be a good thing.

[Pradeep1210]

aahhhhh... I can't believe I have been doing this!

Thanks for the timely help

Actually this code was part of a project in .NET 3.5. I had tested on my home PC, which has Visual Studio 2010 (with target framework set to .NET 3.5) which had the following line of code:

dataRows.ForEach(Sub(dr) dr("Rate") = something)

When I tried to run it on office PC which has Visual Studio 2008, this caused compilation errors and I changed the "Sub" to "Function", and that's where all my miseries began! Looks like I need a few days off from work.

This is a very old project and for some reason the option strict is turned off. Turning it on causes everything to blow out. I was just adding some features to it and fixing the old lines to make it option strict compatible will be a lot of work to do.