HELP! - File Browser Form Control (comdlg32 / 64 bit)

GaryK

New member
Local time
Today, 00:39
Joined
Jul 23, 2010
Messages
5
Hi

I have an Access database that was built with Access 2003 and has been working ok with 2007. However, I have just found that there is a problem if the client machine is running Windows 7 64 bit....

The database has a form with a file browser control that the user clicks on the "browse" button and then selects a file from a windows explorer interface. The purpose of the file browser is so that the user can select a csv file from the file system which is then imported into one of the db tables.

The current solution is using a reference to "Microsoft Common Dialog Control 6.0 (SP3)" (comdlg32). The problem seems that this is not compatible with 64 bit Windows and therefore in References it is flagged as "MISSING".

Here's the code that currently works on 32 bit.....

(cmdBrowse is the form button, txtFilePath is the textbox that the full path and filename are put into and cmDialog1 is the ActiveX control - I guess the bit that doesn't work on 64 bit)
Private Sub cmdBrowse_Click()
Dim VFile As String
On Error GoTo cmdBrowse_Click_Err
ChDrive ("C")
ChDir ("C:\")
cmDialog1.Filter = "CSV Files (*.csv)|*.csv"
cmDialog1.FilterIndex = 1
cmDialog1.Action = 1
If cmDialog1.FileName <> "" Then
VFile = cmDialog1.FileName
Me!txtFilePath = VFile
End If

cmdBrowse_Click_Exit:
Exit Sub

cmdBrowse_Click_Err:
MsgBox Err.Description, , "cmdBrowse_Click"
Resume cmdBrowse_Click_Exit
End Sub
As you can see, the code is very short and simple. Can anyone recommend a way of getting this to work either by modifying what I already have or by a completely different method?

Oh, and it will need to work on XP & Win 7, 32 and 64 bit.

Many Thanks
Gary
 
Two things -

1) You may find it somehwat simpler to use API calls instead of references - this avoid any problems associated with versioning and OS environments. (kind like early binding vs. early binding). The API will work on both 32 & 64 bits.

2) If you still want to use the reference, you may need to look for it - if it was originally for example:
Code:
C:\Windows\system32\comdlg32.ocx

Then you need to remove the reference and browse to:
Code:
C:\Windows\SysWOW64\comdlg32.ocx

But you have to ensure you have the references fixed up when going between the 32 and 64 bit platform -- hence the recommendation for API.


Side note: When one migrates to Access 2010, it may be desirable to rewrite the API call to be compatible with 64-bit but this is required only if you install 64-bit Access (and Microsoft doesn't really recommend installing 64-bit Office and install 32-bit Office, even on a 64-bit OS by default so there's no rush but best to be aware and anticipate the need in future)
 
Thanks for the info Banana....

I have managed to get it working by adding the ocx from the sysWOW64 folder, but am obviously mindful of the issue of 32bit vs 64bit.

Therefore, medium to long term, I would like to go down the API route, but I'm afraid that is beyond my knowledge level. Please could you point me in the direction of how to achieve this with API calls?

Many Thanks
Gary
 
Here's one possible sample code. There's lot more if you google "file dialog api vba" or to that effect.

The code ought to work on both 32-bit and 64-bit OS but when you eventually move to 64-bit Access (must be 2010 or later and installed as such) then this code needs a slight tweaking to work on both 32-bit and 64-bit Access.

HTH.
 
I'm sure that it'll work for all 32-bit Access but for 64-bit Access, it'll need to be rewritten to work correctly. (Note that this is a different matter from working in 64-bit OS, which it should continue to function just fine).

But I do not also expect people to install 64-bit Access as the norm anyway - there's more issues than benefit at this point but that's a consideration we need to take in account for in future. :)
 

Users who are viewing this thread

Back
Top Bottom