Return items in a list before returning the list

[weirddemon]

That was probably bad title, but I'll illustrate what I'm trying to do. I have a method in a class that I need to call several times. The method returns a List(Of String). I'm just grabbing some information from a database.

Public Function GetTestList() As List(Of String)
        Dim int As Integer = 0
 
        Dim cso_list As New List(Of String)
 
        Dim connection As New Connection()
        Dim record_set As New Recordset
        connection.Open("...")
        record_set.Open("...", connection)
        With record_set
            Do While Not .EOF And Not int = 100
                int = int + 1
                cso_list.Add(CStr(record_set("...").Value))
                .MoveNext()
            Loop
        End With
        connection.Close()
 
        Return cso_list
    End Function

You can see in that method that I'm getting the values from the database, adding it to the new list and returning that list.

I then assign that list to a variable in my main class and loop through them.

Dim records As List(Of String) = Me.test.GetTestList
        
        For Each str In records
           'Do stuff
        Next

When looping through the items, I'm showing them in the UI. But that's the quick and easy part. The long part is actually gathering the list. So I want to display the value without returning the list.

Is there a way to do this without updating the UI from the method?

[jmcilhinney]

You could make GetTestList an asynchronous method, which will basically return immediately and set off the data gathering task in a secondary thread. The method that actually does the work could raise events periodically, e.g. once for every item or perhaps every batch of ten items or something like that. The event could be raised either on the secondary thread or the UI thread but any UI updates have to be done on the UI thread regardless.

[jmcilhinney]

You could even simplify the whole thing and just use a BackgroundWorker, passing the items back to the UI thread via the ReportProgress method and ProgressChanged event. That's basically exactly what I was talking about but all the multi-threading and marshalling is already in place for you.

[jcis]

This may sound crazy, but it's pure curiosity: Returning the Recordset from the method to the UI may be an option or this would be a bad practice in .NET?

[jmcilhinney]

This may sound crazy, but it's pure curiosity: Returning the Recordset from the method to the UI may be an option or this would be a bad practice in .NET?

The first thing I would say is that it's wrong to use a Recordset at all in .NET. Ideally everyone would be using ADO.NET in .NET apps rather than ADO. The only reason that I would consider valid for using ADO is when a VB6 app is upgraded to VB.NET using a conversion wizard. Even then, if the app is intended to be modified in future, I would think that converting data access to ADO.NET to be the preferred option.

That aside, the question still arises whether to use a DataSet/DataTable directly in the presentation code. The answer is ideally not. Beginners will generally start that way and Microsoft even make it simple to add DataSets to a form at design time. No professional app should work that way though. There should always be an abstraction so that the UI is not dependent on a specific data access technology. In this case, by the method returning a List(Of String), you could change from ADO to ADO.NET to EF to anything else and the consumer wouldn't have to know or care because the method will continue to return a List(Of String).