Access 2007 app generating error in file_open_save API running on PC with Win7 Pro x64 and Office 2010 x64

I've got an application running at a client site that works fine on their 2007 systems, but they recently upgraded one of their systems to Win 7 Pro and Office 2010 (64 bit versions) and now the declaration statements for the File Open Save api are generating an error (attached).

Is this a simple fix?  Would really prefer not to have to maintain both 32 and 64 bit versions of these applications, and they all have this both the File Open Save (comdlg32) and the Browse Folders (shell32) functionality.

Client indicates they can install the 32 bit version on Terminal Server and allow this one box to access the application via TS, but I would like to hear other alternatives.  

I don't currently have Office 2010, but it looks like I'm going to need to get it, and from what I've read, it doesn't play nice with 2007, so it looks like I'm going to need to get a new computer as well (oh well)!


comdlg32-Error.png
LVL 50
Dale FyeAsked:
Who is Participating?
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Connect With a Mentor Infotrakker SoftwareCommented:
To be clear, my format is wrong. It should be like this:

#IF Windows64 Then
  Private Declare PtrSafe Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
  Private Declare PtrSafe Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal Destination As LongPtr, ByRef Source As Byte, ByVal Length As LongPtr)
#Else
  Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
  Private Declare Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal Destination As LongPtr, ByRef Source As Byte, ByVal Length As LongPtr)
#End If

That should compile.

0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Connect With a Mentor Database ArchitectCommented:
"Office 2010 (64 bit versions) "
Hey Dale.
Well ... at the 2010 mvp summit (2011 in 2 weeks) ... the Access product peeps specifically told us ... "avoid O2010x64 unless you really need super giant large Excel spreadsheets"

Now ... I have to believe that ... there is a 64 bit version of the Win Common Dialog.  The Getz version of course puts a wrapper around the real full on API version.

My class module for Common Dialog uses this version:

http://msdn.microsoft.com/en-us/library/aa155724%28v=office.10%29.aspx

I just tried to track down Romke Soldaat ... plenty of hits ... but not finding a x64 bit version.

I would suggest that you suggest to the client the back track to O2010 x32 ... because I suspect this is just the beginning of problematic issues.

mx
0
 
omgangConnect With a Mentor IT ManagerCommented:
fyed, I am still in the process of migrating an older Access app to a new Win 2008 R2 64-bit server.  The customer installed Access 2010 64-bit on the machine and I've had issues similar to yours with Win API calls.  Try this

Declare PtrSafe Function aht_apiGetOpenFileName Lib ........

I originally found reference to the PtrSafe declaration here http://www.utteraccess.com/forum/Declare-Statment-Ptrsafe-t1942158.html

I was receiving the same errors on the Win API calls in my app at compile time.

FWIW, after all my twiddling around with Access 2010 64-bit I believe we are going to have to swap it out for 32-bit.  Access 64-bit won't see any 32-bit DSNs for the Mas90 accounting software.

OM Gang
0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
If I'm not mistaken, those are 32-bit API calls. As omgang suggests, you'll have to change them to work on the 64 bit platform and include the "PrtSafe" declartion, in most cases:

Private Declare PtrSafe Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
Private Declare PtrSafe Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal Destination As LongPtr, ByRef Source As Byte, ByVal Length As LongPtr)

You could use compiler directives to manage the different platforms for you code. Soemthing like:

#IF Windows64 Then
  Private Declare PtrSafe Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
  Private Declare PtrSafe Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal Destination As LongPtr, ByRef Source As Byte, ByVal Length As LongPtr)
Else
  Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As LongPtr)
  Private Declare Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal Destination As LongPtr, ByRef Source As Byte, ByVal Length As LongPtr)
End If

Then you just include "Windows64" in the conditional compilation options (Tools - <project name> Properties, first page at the bottom). You can twiddle that as needed for different platforms - that is, if you're deploying to the 64-bit platform, you would include the value in that section. If not, just delete the value from that option.
0
 
Dale FyeAuthor Commented:
Thanks, guys.

The client sent me another email indicating that the reason for the upgrade to 2010 was something about a new Business Intelligence product they purchased (Spotfire) which required that they upgrade to office 2010.  I'll have to check to see whether it required 2010 x64 or would work with x32.  Either way, I doubt the client will be able to get a refund on the x64 software so they may not want to go that route.

Scott, I've never used compiler directives before, or Conditional Compilation Arguments.  If I add this conditional IF will the application compile to an mde in 2007 and then allow me to set the Conditional Compilation Argument?  Or will my client need to recompile the accdb on his A2010 box?

Dale
0
 
Dale FyeAuthor Commented:
The answers to the questions above are:

1.  If I add this conditional IF will the application compile to an mde in 2007 and then allow me to set the Conditional Compilation Argument? NO

2.  Or will my client need to recompile the accdb on his A2010 box? Yes

Have updated my code with conditional #IF statements and have sent it to them for testing.  I followed omgangs hyperlink and then another one off that and read a blog post dated March 28, 2010 that indicates this is also a problem with A2010x32 on a x64 OS.

0
 
Dale FyeAuthor Commented:
Scott,

Thanks for the clarification, but I had already picked up on that via the blog post mentioned above.  And it does compile, so long as I set my Win64 variable to 0, but when I set it to 1 on my x32 system.

However, my clients IT guy has way too much time on his hands and tested this solution on their computer and it is working fine.  Thanks for the recommendation.  Only problem I have now is giving the client the accdb instead of an accde.  I'll have to live with this until I purchase a x64 system.
0
 
Dale FyeAuthor Commented:
Thanks, again.  Don't know how I've managed to program all these years without using the conditional compilation arguments.
0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
"If I'm not mistaken, those are 32-bit API calls"
Yes.

0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
So then PtrSafe  does make the difference?
I've seen a lot of confusion on that ... just wondering ...

mx
0
 
Dale FyeAuthor Commented:
Joe, the blog post I referred to above goes into a bit more detail, and identifies a couple of other issues some of the x32 API calls require additional tweaks.
0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
But it solved your issue ... again just wondering ?

mx
0
 
Dale FyeAuthor Commented:
Yes, at least for now.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Joe/Dale:

Have you seen this article:

http://msdn.microsoft.com/en-us/library/ee691831.aspx
0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
@fyed
Cool!

@Scott
I have now :-)
thx.mx
0
 
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
Not related per se, but have you seen the attached file?


Access2003ToA2010RibbonMenuLocat.zip
0
 
Dale FyeAuthor Commented:
Scott,

Thanks for posting that.  Have any of you MVPs asked MS why they haven't developed 64 bit versions of mscomctl.ocx and mscomctl2.ocx?

That article implies that I'm going to encounter problems with treeview and listview controls on my applications when they move to O2010x64 on an x64 system as well.  I guess MS is busy trying to support its partners that create 3rd party applications.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.