32-Bit File Open Not Working in 64-Bit

[richlocus]

Hello:
I am converting an Access 32-Bit Access application to the 64-Bit Access application.

In the 32-bit version, the code presents a file-open dialog box which allows me to navigate and open a file.

In the 64-bit version, it just ignores the command and doesn't present a file open-dialog box.

The attachment shows where it fails. I recall reading that some file-open functions from the 32-bit code don't work in 64-bit, but I'm not sure how to get around this.

Is there a substitute in the 64-bit version?

Thanks,
Rich Locus

[HansV]

As far as I know, it should work, but I don't have 64-bit Office myself, so I cannot test it.
Consider using Application.FileDialog instead.

[Jay Freedman]

The declaration of the GetOpenFilename API function has to be changed to the 64-bit version. The article at https://jkp-ads.com/Articles/apideclarations.asp has the necessary version, which you can copy and paste into your code. It also shows the changes in the data types of the members of the OPENFILENAME structure, such as hwndOwner, and you may have to change some of your other code to match. The section https://jkp-ads.com/Articles/apideclara ... me_LongPtr will help with that.

[richlocus]

Hans and Jay:
Thanks for the reply. I will proceed with testing.
Rich

[richlocus]

Jay:

Thanks for your suggestions and the articles you referenced.

I could not find a place to attach images of .jpg examples, so I'm pasting text examples at the bottom.

I am still getting a failure when attempting to issue this statement:
X = GetOpenFileName(OpenFile)

Nothing happens, no error message, and no open file dialog box appears. It ignores the statement.

When I change it to Application.GetOPenFileName(OpenFile) I get a compile error. (Method or Data Menber Not Found) It doesn't like when I prepend with "Application" as shown ---> Application.GetOpenFileName(OpenFile).

The code "executes" the statement but no file dialog box is displayed. It just moves on without doing anything or giving an error message.

I reviewed the documentation referenced in your links to articles, and perhaps I am not defining my Declare statements properly based on your article. If that is the case, please let me know.

As I mentioned, I'm running Access 2016 on a 64-bit Office platform. I validated that all the appropriate References were included for Office 2016. I'm assuming Access doesn't have it's own separate references.

Thanks

EXAMPLES:

Option Compare Database

Private Declare PtrSafe Function GetOpenFileName Lib "comdlg32.dll" Alias _
"GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

Private Declare PtrSafe Function GetSaveFileName Lib "comdlg32.dll" Alias _
"GetSaveFileNameA" (pOpenfilename As OPENFILENAME) As Long

Private Type OPENFILENAME
lStructSize As Long
hwndOwner As LongPtr
hInstance As LongPtr
lpstrFilter As String
lpstrCustomFilter As String
nMaxCustFilter As Long
nFilterIndex As Long
lpstrFile As String
nMaxFile As Long
lpstrFileTitle As String
nMaxFileTitle As Long
lpstrInitialDir As String
lpstrTitle As String
flags As Long
nFileOffset As Integer
nFileExtension As Integer
lpstrDefExt As String
lCustData As LongPtr
lpfnHook As LongPtr
lpTemplateName As String
End Type

Private mstrFileName As String

Private mblnStatus As Boolean

[HansV]

Application.GetOpenFilename is Excel VBA. The GetOpenFilename function you're trying to use is a Windows API function, not a member of the Access Application object.
What do you pass as the lngAppInstance argument when you call the OpenFileDialog function? More in general: how do you call it?

[SpeakEasy]

Diagnosing issues with API calls means it helps if we can see all of the code involved. So far, you have not provided that, which makes diagnosis almost difficult, if not impossible.

That being said, try changing

.lStructSize = Len(OpenFile)

to

.lStructSize = LenB(OpenFile)

[richlocus]

SpeakEasy:

Bingo!!!

Thank you very much!!

I updated the one statement .lStructSize = Len(OpenFile) to .lStructSize=LenB(OpenFile)
AND IT WORKED AS PLANNED!!

Why would Access 32Bit use "Len" and Access 64Bit use LenB? That one little statement fixed everything.

I have looked for that needle in a haystack for two days and couldn't find anything in the internet posts from all sorts of sources.

Just FYI, here is the code below. The input to this Access application is a set of tab-delimited files (The user repeats imports 6 times for six separate Tab Delimited Files). These files are exported from an ERP system. My users just click on a button and it imports Tab Delimited Files into a table using the hidden Input/Output Specifications.

I Attached The Code For Your Information

Thanks again,
Rich Locus

[SpeakEasy]

>Why would Access 32Bit use "Len"

Bad practice and bad examples from Microsoft. Without going into details, structures (UDTs) get padded to ensure something called byte alignment. In the 32bit world, many of the datatypes are actually 4 bytes in size, and the natural word size is 4 bytes, so there may be no packing, and thus Len (which ignores packing bytes) coincidentally works correctly (but not always). In the 64bit world, with an 8 byte word size, thereis more padding, and Len fails. LenB, on the other hand, counts the padding correctly on both 32bit and 64bit platforms

In other words, you should really have been using LenB in Access32 as well, but have been misled by examples available on the internet ...