ListView Disappears...

[samsmithnz]

I'm having trouble with the new vb.net Listview control. I have it set to report, and I have 4 columns.

 

I've attached a picture of what I mean by the listview disappearing.

 

This is the code that populates the listview:

 

   Private Sub UpdateTrackList(ByVal intAlbumKey As Integer)
       Dim adoRS As ADODB.Recordset
       Dim lstItem As ListViewItem

       'Remove all items
       lstTracks.Clear()

       adoRS = New ADODB.Recordset()

       adoRS.Open("SELECT * FROM Tracks WHERE AlbumKey = " & intAlbumKey & " ORDER BY TrackOrder", adoConn)

       Do While Not adoRS.EOF
           lstItem = New ListViewItem()
           lstItem.Text = adoRS.Fields("Name").Value
           lstItem.SubItems.Add(adoRS.Fields("TrackOrder").Value)
           lstItem.SubItems.Add(adoRS.Fields("Key").Value)
           lstItem.SubItems.Add(adoRS.Fields("FileName").Value)
           lstTracks.Items.Add(lstItem)
           adoRS.MoveNext()
       Loop

   End Sub

[Volte]

It may just be busy. Try putting an Application.DoEvents right after the

lstTracks.Items.Add(lstItem)

line.

 

Also, I noticed you are using regular ADO - since this is .NET, you may want to consider switching to ADO.NET. Look in your MSDN for tons of information about ADO.NET (System.Data namespace).

[samsmithnz]

Nope, Application.DoEvents doesn't do it. Still blank.

 

Here are my listview properties:

 

       '
       'lstTracks
       '
       Me.lstTracks.Columns.AddRange(New System.Windows.Forms.ColumnHeader() {Me.ColumnHeader1, Me.ColumnHeader2, Me.ColumnHeader3, Me.ColumnHeader4})
       Me.lstTracks.FullRowSelect = True
       Me.lstTracks.Location = New System.Drawing.Point(8, 40)
       Me.lstTracks.MultiSelect = False
       Me.lstTracks.Name = "lstTracks"
       Me.lstTracks.Size = New System.Drawing.Size(384, 320)
       Me.lstTracks.TabIndex = 3
       Me.lstTracks.View = System.Windows.Forms.View.Details

 

Also I just double checked and I'm definitly using ADO.NET, but i'm just not using the dataset object yet, still using the recordset.

 

The dataset object is nice, but I really have no need to have things like relationships in memory.

[Volte]

DataSet is just one part of ADO.NET. There is much more to ADO.NET than just that. It is certainly much more flexible than ADO. There is really no reason to use ADO over ADO.NET. You just need to learn how to use it. :)

[samsmithnz]

DataSet is just one part of ADO.NET. There is much more to ADO.NET than just that. It is certainly much more flexible than ADO. There is really no reason to use ADO over ADO.NET. You just need to learn how to use it. :)

 

I agree there is a lot more, but you commented that I wasn't using ado.net, when in fact I am. I'm just using an older part of it.

 

But back on topic, any other idea on way this may be failing?

[dynamic_sysop]

change this..... lstTracks.Clear()

to this....

lstTracks.Items.Clear() '/// must be Items.Clear().

[Volte]

ADO is not an "older part" of ADO.NET - the only thing the same between ADO.NET and ADO is part of the name.

[samsmithnz]

Thanks dynamic_sysop, that did the trick exactly, subtle, but I understand why that would have been ruining it!

 

ADO is not an "older part" of ADO.NET - the only thing the same between ADO.NET and ADO is part of the name.

 

i dont totally agree with you VolteFace.

[Volte]

ADO and ADO.NET are both in the "ADO" family, but they are not versions of each other, just as Visual Basic and Visual Basic .NET are almost nothing alike.

 

Plus, since ADO.NET is managed and ADO is not, you should always use ADO.NET over ADO in a .NET application. If you are using unmanaged code, ADO is still a viable choice though.

[samsmithnz]

Why is a recordset unmanaged if I'm using it with ado.net and its available?

[Volte]

But you're not doing it with ADO.NET... you're using from ADO. You referenced the ADO library from .NET, but that does not mean it is managed code. Anything in the ADODB library is legacy ADO, while anything in System.Data is ADO.NET.

 

It *is* possible to fill DataSets (ADO.NET) with Recordsets (ADO), but even if you are doing this, there is no reason to in this case.

[samsmithnz]

Ahhhh. I did not relieze that I had to use the system.data namespace. I thought I was using ADO.NET by referencing the adodb namespace in the .NEt tab.

 

My mistake. My bad, you're right.

 

Now this means I have to convert this application again (this application has been by vb6 to vb.net test case)

[divil]

There is no Recordset in ADO.NET :)

[samsmithnz]

I blame Microsoft. It seemed logical to me to add the ADODB namespace and assume I was using ADO.NET, and that ADO.NET was backward compadible.

 

Bloody MS! :rolleyes: (biting the hand that feeds me) :eek:

[samsmithnz]

OK, so we worked out I wasn't actually using ADO.NET, but then VolteFace said that ADO is managed, but when I go to references, I can see ADODB under the .NET tab, and if I go to the COM tab, I can still see all of the normal COM ADODB references....

 

How can I tell if the .NET ADODB is/isn't managed?

[Volte]

ADO is NOT managed, but ADO.NET is.

 

However, upon examination with Assembly Viewer, it appears the adodb.dll included with .NET is a managed wrapper for interop with the old ADO methods.

 

You should still use ADO.NET though. If you use ADO it will probably force you to install the MDACs and stuff if you distribute your app.

[samsmithnz]

ADO is NOT managed, but ADO.NET is.

 

However, upon examination with Assembly Viewer, it appears the adodb.dll included with .NET is a managed wrapper for interop with the old ADO methods.

 

You should still use ADO.NET though. If you use ADO it will probably force you to install the MDACs and stuff if you distribute your app.

 

Ok that makes sense. Thanks for clearing that up. I've been reading some articles and ADO.NET is the best for distributed applications, but the article recommended ADO for desktop applications, it has less overhead and is quicker...

 

I should investigate now just exactly what the .NET framework installs. at 15MB hopefully it includes the Mdac :)

 

thanks for understanding my protests VolteFace...