FileDialog Object ceased to function (User-Defined Type not Define

[EJ Williams]

I have been using the FileDialog object of the Access Application to create a
file browser for users to specify the path to a file to store in a table. It
had been working fine but recently began reporting the error above. I'm not
sure if this was caused by installation of a patch or what.

Anyone have any insight as to what may be causing this?

TIA,

Eric

 

[Allen Browne]

Use this API call instead:
http://www.mvps.org/access/api/api0001.htm

The FileDialog always had problems anyway (e.g. offering to do a SaveAs that
just never worked in Access.)

 

[EJ Williams]

I'm aware of the Windows API call and have used it in the past, prior to the
addition of a native Access object, but would rather utilize Access objects
where possible. This simplifies things for the client as the objects are
documented within the Access VBA help.

By the way, I have had use for the "Save As" file dialog when prompting
users for a location to extract file data stored as BLOBs. Not a routine
exercise but there is the occassional requirement.

I'll fall back on the API function if necessary.

Thanks,

Eric

 

[Douglas J. Steele]

While it may appear that it simplifies things, as Allen points out, the
built-in File Dialog is buggy.

It's also NOT an Access object: it's an Office object, so that you need to
set an additional reference in order to make it work. Anytime you add a
reference, you increase the possibility of a problem with your References.

The API approach is definitely superior.

 

[EJ Williams]

Doug,

I am not going to debate whether or not it is buggy.

Also the FileDialog object IS AVAILABLE NATIVELY as a property exposed by
the Application object. This means I DO NOT need an additional reference to
use the object. I need only reference it as a generic object.

That being said, the issue ws that I DID try to access it as a FileDialog
object rather than through a generic object class. I had also referenced the
MsoDialogType enumeration that is part of the Office library. This was easily
rectified as well by setting the type by value rther than using the enum.

THANKS AGAIN FOR ALL YOUR HELP!