Try catch if selected excel file is blank

Question

3.00/5 (1 vote)

See more:

Hello I have a program that imports an excel file using the oledb in vb.net. This program imports the excel spreadsheet into a datagridview. On opening the program will ask the user to choose an excel file to open, however if the user inputs nothing or presses the cancel button the program will crash. I'm trying to find a way to prevent a user from canceling or leaving the excel filename blank. I'm hoping this will be done using a try catch block but I'm not exactly familiar with try catch in vb.net. If anyone has any suggestions or solutions for this I would greatly appreciate it. This is what I found on MSDN.

VB

Dim dlg As New OpenFileDialog()
        dlg.Filter = "Excel Macro Enabled Files|*.xlsm*|Excel Files|*.xls|Excel 2007 Files|*.xlsx|All Files|*.*"
        If dlg.ShowDialog() = DialogResult.OK Then
            '      excelObj = New ExcelObject(dlg.FileName)
            txtFilePath.Text = dlg.FileName

            Me.ExcelWriteBtn.Enabled = txtFilePath.Text.Length > 0
            Me.closexlsbtn.Enabled = txtFilePath.Text.Length > 0
        Else
            messagebox.show("Please Select a File")
            dlg.showdialog()
        End If

Posted 14-Aug-13 4:45am

CAS1224

Updated 14-Aug-13 8:07am

v3

Add a Solution

Comments

ZurdoDev 14-Aug-13 11:15am

Your solution of looking for the file first is better than using a try catch. What won't work about that approach?

Sergey Alexandrovich Kryukov 14-Aug-13 11:53am

It's not about try-catch. If you look at the code, you will see that it's incomplete. There is one criterion — file not found. But how to determine that the document is "empty".
I think the problem is: there is no such concept as "empty" Excel spreadsheet. OP needs to define it, apply, or just ignore this criterion.

I actually put an answer...
—SA

ZurdoDev 14-Aug-13 11:59am

No, the OP said, "I'm trying to find a way to prevent a user from canceling or leaving the excel filename blank."

Sergey Alexandrovich Kryukov 14-Aug-13 12:06pm

Why "no"? I commented on your comment to my answer.
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-08-14T05:57:00

Solution 1

So, why ignoring "empty" documents? Is it really important. I don't think people create empty documents and save as files intentionally. The probability of it is hardly much more than the probability of totally irrelevant or even random Excel documents.

So, please look at my comment to the question. The real problem is that Excel does not support the concept of "empty document" (unlike plain text files, for example). You need to think if this criterion makes sense. I doubt it.

[EDIT]

Probably I misunderstood you. Thanks to ryanb31 for pointing it out. Then the problem is much simpler, it is just reduced to UI. When you say "the program will ask the user", you should ask properly. The standard file open dialogs return the value which reflects the user's decision. When Cancel was pressed, you know that from return value. The dialog won't allow user to select no files without cancellation.

As simple as that.

—SA

Posted 14-Aug-13 5:57am

Sergey Alexandrovich Kryukov

Updated 14-Aug-13 6:17am

v2

Comments

ZurdoDev 14-Aug-13 12:00pm

The title suggests a blank file but if you read the notes the OP says, "I'm trying to find a way to prevent a user from canceling or leaving the excel filename blank."

Sergey Alexandrovich Kryukov 14-Aug-13 12:05pm

Yes, yes, I know. I just don't think the API offers the method to identify such file without any analysis. And it makes messing with it not very sensible. Do you see the point?
—SA

ZurdoDev 14-Aug-13 12:10pm

No. They are not asking how to know if the file is empty, but if the filename is not supplied by the user.

Sergey Alexandrovich Kryukov 14-Aug-13 12:14pm

Or really? I missed it, thank you for the note. In this case, the answer would be simple...
—SA

Sergey Alexandrovich Kryukov 14-Aug-13 12:18pm

So, I fixed the answer, after [EDIT].
—SA

CAS1224 14-Aug-13 12:25pm

ok, sorry for the confusion. I'm using an openfiledialog and I'm trying to prevent a user from pressing the cancel button. I've updated my code example

Sergey Alexandrovich Kryukov 14-Aug-13 12:47pm

No, don't prevent it. Just force the user to select the file again. Imagine you have some "Process" or "Start" button, and the processing needs the valid file. When a file is not selected, disable it. Or enable, but if the file is not selected, start with showing this dialog.

Something like that, pretty simple. I just don't know all your detail. You just need to design consistent and clear UI...

—SA

CAS1224 14-Aug-13 14:10pm

I've added additional code. Now if my user clicks the cancel button a message box appears and the openfiledialog reloads. However if I try and chose a file the program crashes once again with the error message "COMexception has occured"

Sergey Alexandrovich Kryukov 14-Aug-13 15:04pm

This is not directly related to your question. Use the debugger. Create and show code sample. We don't have enough information; there are too many ways to screw up things.
—SA