[RESOLVED] [02/03] Trying to read floppy

[GrimmReaper]

I have a sub :

    Private Sub SSLoadDir(ByVal SSDirList As String)
        Try
            For Each SSFolderList As String In Directory.GetDirectories(SSDirList)
                Dim SubFolderList As String = lstSSDir.Items.Add(SSFolderList)

            Next
                  Catch ex As System.IO.IOException
                      MessageBox.Show("Unable To Read Disk!", "Scoresprite", MessageBoxButtons.OK, MessageBoxIcon.Error)
            SSStartUp("C:\")
        Catch ex2 As Exception
            SSStartUp("C:\")
        End Try

The prupose of which is to listall the directories into a listbox.
When I call this sub like :

        SSLoadDir("A:\")

and there's no floppy in the drive i get the windows No disk error, then mine. Isn't there a way to show only my error?

[jmcilhinney]

Instead of relying on an exception you should test whether the drive is ready first. In .NET 2.0 and later you'd do that with a DriveInfo object. In .NET 1.x I imagine it's a painful experience involving WMI or the Windows API.

[GrimmReaper]

Thanx for your advice sir.
any ideas on which api or method of wmi i must search for?
2003 sucks, it's not the first time i had to do something which i simply couldn'ti with 2003

[jmcilhinney]

As I said, you could do it with WMI, probably with the Win32_DiskDrive class I'd guess. If it can be done with the Windows API, and I don't know if it can, I'd be consulting the API Guide first. It groups functions by area of functionality so it should make it easier to find what you need.

[GrimmReaper]

Yes! I've got it! I used the GetVolumeInformation API

This is what I've done :

    Private Declare Function GetVolumeInformation Lib "kernel32" Alias "GetVolumeInformationA" _
       (ByVal lpRootPathName As String, ByVal lpVolumeNameBuffer As StringBuilder, _
       ByVal nVolumeNameSize As Integer, ByVal lpVolumeSerialNumber As Integer, _
       ByVal lpMaximumComponentLength As Integer, ByVal lpFileSystemFlags As Integer, _
       ByVal lpFileSystemNameBuffer As StringBuilder, ByVal nFileSystemNameSize As Integer) As Integer

    Private Sub SSLoadDir(ByVal SSDirList As String)
        Try

            Const MAX_PATH As Integer = 260
            Dim iSerial As Integer
            Dim iLength As Integer
            Dim iFlags As Integer

            Dim sbVol As New StringBuilder(MAX_PATH)
            Dim sbFil As New StringBuilder(MAX_PATH)

            GetVolumeInformation("A:\", sbVol, MAX_PATH, iSerial, iLength, iFlags, sbFil, MAX_PATH)

            If Not sbVol.Equals(String.Empty) Then
                For Each SSFolderList As String In Directory.GetDirectories(SSDirList)
                    Dim SubFolderList As String = lstSSDir.Items.Add(SSFolderList)

                Next

            End If
        Catch ex As System.IO.IOException

            MessageBox.Show("Unable To Read Disk!", "Scoresprite", MessageBoxButtons.OK, MessageBoxIcon.Error)
            SSStartUp("C:\")
        Catch ex2 As Exception
            SSStartUp("C:\")
        End Try
        lblCurrDir.Text = SSDirList
        SSCurrLblStr = SSDirList
        SSCurrTTip = SSDirList
    End Sub

It works
But it actually defeats the whole purpose of Try & Catch blocks.
I think this thread is even more evidence that I need either VB 2008 or 2005, I'll try to convince my boss (again!), but i can't go on battling like this.
Wish me luck!
Thank you!

[jmcilhinney]

It works
But it actually defeats the whole purpose of Try & Catch blocks.

That's certainly not the case. That's like saying that you shouldn't bother testing a number to see if it's zero before dividing it into another number because you can just catch the DivideByZeroException that will be thrown. Prevention is almost always better than cure.

Sometimes it's unavoidable but most application-level code should never throw any exceptions at all. The only things that should throw exceptions are things that are beyond your control, like connecting to a database with invalid credentials or deleting a file that is in use. Any conditions that can be tested beforehand to avoid exceptions generally should be, unless doing so is particularly complex or time-consuming.

This situation is complicated by the fact that you have to use unmanaged code but it's still preferable to unnecessarily throwing an exception.