How do I get an Open File dialog for Access 2010 64bit? Normally I would use the common dialog control but that is 32bit and cannot be used with Access 2010 64 bit.
相关问题
- Error handling only works once
- Excel formula in VBA code
- Excel VBA run time error 450 from referencing a ra
- Importing data from MS Access db to PostgreSQL db
- DoCmd.TransferSpreadsheet is not recognizing works
相关文章
- Unregister a XLL in Excel (VBA)
- numeric up down control in vba
- Declare a Range relative to the Active Cell with V
- COALESCE, IFNULL, or NZ() function that can be use
- CurrentDb.RecordsAffected returns 0. Why?
- How to disable changes in a cell using vba?
- MsgBox Yes/No Excel VBA
- Rounding up to nearest higher integer in VBA
You can use the built in file dialog. It been there since access 2003.
You can late bind if you wish:
above needs: Microsoft Office 14.0 Object library
If you remove the reference to the 14.0 object library, then the following code will work without any references:
So, above works in runtime or regular edition from 2003 onwards, and also works for either 32 or 64 bit editions of access 2010.
I've never used a control for the open File dialog as it's just a wrapper for the API call anyhow. Call the standard Windows File Open/Save dialog box In addition there can be distribution and versioning problems with controls so I do my best to avoid them.
I missed the 64-bit Access detail. It's very unlikely that you should be running it, but if you are, here is an article for your consideration that explains how you have to alter your API call to work -- you have to use the new long pointer data type:
Compatibility Between the 32-bit and 64-bit Versions of Office 2010
If you alter the API code accordingly, it should work fine on 64-bit Access.
But you should really ask why you're using 64-bit Access. It's really not at all recommended by MS that anyone use 64-bit Office unless they have specific reasons why they need it (such as needing to use the extra memory it provides, particularly for things like complex Excel spreadsheet models). Access is definitely not one of the apps that benefits much from the conversion to 64-bit.
Detailed discussion of the subject:
In short, most people shouldn't be running 64-bit Office, precisely for the reason you encountered -- it causes legacy code with outside dependencies on 32-bit components and APIs to fail.
I've just been wrestling with resolving this issue in a 64-bit version of Excel 2013.
A combination of...
LongPtr
data type for 3 of the items (hwndOwner
,hInstance
,lpfnHook
) in theOPENFILENAME
structure passed toGetOpenFileNameA
Len
function with theLenB
function when obtaining the size of theOPENFILENAME
structure (as mentioned by Max Albanese)...did the trick, thanks to guidance documented here: https://gpgonaccess.blogspot.co.uk/2010/03/work-in-progress-and-64-bit-vba.html
First of all, the "CommonDialog Class" doesn't even appear to work on a 32-bit version of Office. It gives the same OleDb error. As one of the commenters points out, this isn't the control you should be using. And while there might be another ActiveX control you could use, there's really no guarantee that it will be available on every machine that you want to deploy your database on. My dev box has Visual Studio 6, VS 2008, and VS 2010 on it, in addition to Office and other programs, all of which provide ActiveX DLLs that a typical user could not be expected to have. Additionally, many of these libraries are not redistributable, or pose unique installation hurdles that may simply not be worth the trouble.
By far, the simplest, most universal solution is to call the Open dialog from the Windows API. It's located in comdlg32.dll, which is available on every version of Windows you could possibly be targeting, and doesn't impose any dependencies on comdlg32.ocx. It also provides better performance than using an ActiveX control because it doesn't require an additional module to be loaded into memory.
The code that is required isn't very complicated either. You need to provide a declaration for the function
GetOpenFileName
, which creates the Open dialog box. It takes a single parameter, an instance of theOPENFILENAME
structure that contains information used to initialize the dialog box, as well as receiving the path to the file selected by the user. So you'll also need to provide a declaration of this structure. The code in VBA would look something like this:There are also a couple of constants you can pass as flags to customize the dialog's behavior. For completeness, here's the full list:
And for convenience, I've wrapped this whole mess inside of a helper function that you can call from within VBA. It accepts as parameters the properties you will most commonly need to set for the open file dialog, handles calling the Windows API itself, and then returns either the full path to the file selected by the user, or an empty string (
vbNullString
) if the user clicked the Cancel button. You can test the return value in the calling code to determine which course of action to take.Wow that ended up being long. There are a lot of declarations you'll need to copy and paste into a module, but the interface you actually have to deal with is surprisingly simple. Here's a sample of how you might actually use this in your code to show the open file dialog and get the path to a file:
The longest part of writing and testing this solution was actually trying to find how to open the VBA editor and write a macro in Access. The Ribbon might be a great invention for people who use the menu primary for "Paste" and "Save", but what a pain. I spend all day using software, and I still can't find stuff. [/rant]
This guy has a tool that generates code that is 64 bit compatible for opening a file. It is freeware.
http://www.avenius.de/en/index.php?Products:IDBE_Tools
This was the only thing that worked.