Common Dialog Control Not Available

[royalrochelle]

I was trying to use the Common Dialog Control in Access 2003 but I found out it is not available. During my research I found that I need to purchase Visual Basics 6.0 or Visual Studios.Net. I have no problems adding this software to my computer, the only problem I have is, the user doesn't have Visual Basics 6.0 or Visual Studios.Net. If I add the common Dialog Control to my code is does my the user need to install this software too? If so, is there a way I can use the Common Dialog Control without the extra software?

Thanks in advance for any help.

[RuralGuy]

Use the API instead.

[royalrochelle]

Thank you so much! This worked.

[RuralGuy]

Glad I could help.

[Moniker]

Err, just add the reference to Microsoft Office x.0 Object Library (where the x is a version number).

This exposes the FileDialog object, and you don't need the 100+ lines of API code. Instead of all that, you would use something like this to open a file:

Sub OpenFile()

    Dim dlg As FileDialog
    Dim dlgTitle As String
    
    Set dlg = Application.FileDialog(msoFileDialogFilePicker)
    With dlg
        .Filters.Clear
        .Filters.Add "Excel Files", "*.xls"
        .AllowMultiSelect = False
        .Title = "Select the Excel file to import"
        If .Show Then
            fGetFileFolder = .SelectedItems.Item(1)
        End If
    End With
    
    Set dlg = Nothing

End Sub

Once you have the FileDialog declared, just type dlg. and let IntelliSense show you all the things exposed (Filters, Titles, what .Show does, etc.).

I believe you'll find it much more maintainable and easy-to-understand, and if something goes wrong, you won't have to struggle through that API code trying to figure out what might be wrong.

[RuralGuy]

AFAIK, API's do not have versioning problems.

[Moniker]

Hmmm...

I've had no issues between Access 2K through 2K7 doing what I suggested, and I'd imagine that the API may be altered a little in Vista (not tested that). I know what you mean in that if I develop in Access 2003 (Office 11.0) and send it to an Access 2000 user (Office 10.0), that can cause issues as the reference will automatically move forward but not backward. Unless you're deploying to multiple versions of Access, the references are not an issue. Even then (and I know this part can get a little complex), you can trap unknown reference errors and correct them.

I get your point though. It's just that the reference is a lot cleaner and easier to debug/maintain should you need to do that.

[boblarson]

Originally Posted by Moniker

Hmmm...

I've had no issues between Access 2K through 2K7 doing what I suggested, and I'd imagine that the API may be altered a little in Vista (not tested that). I know what you mean in that if I develop in Access 2003 (Office 11.0) and send it to an Access 2000 user (Office 10.0), that can cause issues as the reference will automatically move forward but not backward. Unless you're deploying to multiple versions of Access, the references are not an issue. Even then (and I know this part can get a little complex), you can trap unknown reference errors and correct them.

I get your point though. It's just that the reference is a lot cleaner and easier to debug/maintain should you need to do that.

I've just run into a reference problem with using the Office reference (not my choice - it was done before I got on this project) and I've NEVER had any problems with using the API. So, for my money - I will use the API over setting a reference any day. That's just my preference.