J-Walk & Associates, Inc.

PUP v7.1 Is Coming

Several people have pointed out to me that PUP v7 does not work with 64-bit Excel 2010 Beta.

The problem is with the API function calls.

NOTE: I deleted some of this post because the information is wrong.
See: PUP v71. Revisited.

 Fortunately, it's an easy fix. All of the API function declarations need to be modified by adding PtrSafe between Declare and Function. For example, the declaration that starts like this...

Private Declare Function HtmlHelp Lib "HHCtrl.ocx" Alias "HtmlHelpA" ...

... must be changed so it starts like this:

Private Declare PtrSafe Function HtmlHelp Lib "HHCtrl.ocx" Alias "HtmlHelpA" ...

PUP v7 consists of 87 files, and thirteen of them (including pup7.xlam) need to be modified. 64-bit Excel users can identify these files because you'll get an error message when you try to run the utility contained in that file. If you've purchased PUP v7 with the source code option, you can make the changes yourself, if you're so inclined (make sure you save the file after changing it). Otherwise, just be patient.

I hope to have a new version available within a few weeks a month or so.

The new version (called PUP v7.1) will replace the current version, and it will be compatible with both 32-bit and 64-bit versions of Excel. It will have no other new features, and there will be no charge for current PUP v7 licensed users to upgrade. There's really no reason to upgrade unless you use (or plan to use) the 64-bit version of Excel 2010.

I'm curious... How many of you have tried the 64-bit version of Excel 2010 Beta? Do you plan to? If so, why?

- Reader Comments -

Following are comments in response to this item.
The most recent comment is at the bottom.

1. By gary. Comment posted 04 January, 2010 12:40pm

   the only reason i have the 32 bit version of office 2010 installed is i still need to use excel 2003 to actually get some work done and the 64 bit version can't be installed with any 32 bit version.
2. By squiggler. Comment posted 04 January, 2010 1:21pm

   I'm running the beta of office 2010, I decided to try the 64-bit since I am running 64bit Windows 7, other than that I dont see any benefit, I am sure I would with more than 4gb memory
3. By Michael. Comment posted 04 January, 2010 2:42pm

   Hi John -
   
   Is it PtrSave or PtrSafe? It's one way at the top, 'tother in the middle.
   
   HNY!
   
   ...mrt
4. By John Walkenbach. Comment posted 04 January, 2010 3:53pm

   Sorry, it's PtrSafe. I fixed the typo.
5. By Rod. Comment posted 06 January, 2010 1:58am

   I run Windows 7 64 bit, so thought I would try Office 2010 Beta 64 bit - just curious1
6. By Charlie. Comment posted 07 January, 2010 1:43am

   John,
   
   PtrSafe is not the only change that needs to be made. For example, the data type of hwndCaller used in the HtmlHelp function must be changed from Long to LongPtr. The following link is an excellent reference for ensuring compatibility between 32 and 64 bit versions of Excel 2010. It explains the new data types as well as showing how conditional compilation can be used in the VBA.
   http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx
   
   Charlie
7. By John Walkenbach. Comment posted 07 January, 2010 5:44am

   I've seen that article, Charlie. That's what originally led me think it might be a big job.
   
   So far, I've found only one problem with PUP v7 running under 64-bit Excel that isn't solved by adding PtrSafe. It's in the "Save With Backup" utility (which uses SHBrowseForFolder). This one crashes 64-bit Excel. Fortunately, there's a way to browse for a folder using VBA, so I'll be revising that one to use the FileDialog object.
8. By Charlie. Comment posted 07 January, 2010 9:40pm

   John,
   
   Check out the BROWSEINFO structure. Change the declaration of all pointer variables in the structure from Long to LongPtr for Excel 2010. Since the address of this structure is passed as an argument to SHBrowseForFolder,the incorrect structure size due to the wrong pointer variable declarations will cause the function to crash in 64 Bit Excel as you experienced. In addition, make sure that all Windows API functions have their pointer variables declared as LongPtr. Incidentally, as you are probably aware, the SHBrowseForFolder function is used in a couple of other functions in PUP 7. I don't have a 64 bit computer to test this, so these are just my guesses for the cause of the crash. I think that your original thought that it might be a big job may turn out to be correct.
   
   Charlie
9. By Charlie. Comment posted 08 January, 2010 8:54am

   John,
   
   Here's a point that I overlooked. In the function declaration perhaps shell32.dll should be shell64.dll. Since I don't have 64 bit Windows, I can't check to see whether Microsoft changed the name for the 64 bit version.
   
   Charlie
10. By John Walkenbach. Comment posted 08 January, 2010 9:27am

    Thanks, but it's a moot point. Like I said, I'll just use the Application.FileDialog object. It's much easier, and provides a better directory browsing dialog box.
11. By Michel. Comment posted 09 January, 2010 5:57pm

    I'm into photography so I have 8 GB RAM which requires Windows 7 x64. So I've pretty much made the jump to x64 whenever possible, include Office 2010 Beta
    
    Keep up the good work - I'm a PUP lover, hear me roar!
12. By John Walkenbach. Comment posted 12 January, 2010 3:11pm

    Charlie, you are right. It's not as easy as I thought it would be.
13. By Yuhong Bao. Comment posted 25 January, 2010 11:13am

    "In the function declaration perhaps shell32.dll should be shell64.dll. Since I don't have 64 bit Windows, I can't check to see whether Microsoft changed the name for the 64 bit version."
    No they didn't. In fact, what they did was to redirect access to the System32 folder to SysWOW64 for 32-bit apps.
14. By Jan Karel Pieterse. Comment posted 28 January, 2010 10:32am

    So let's start gathering the correct declarations for API functions, OK?
    
    Here's a start:
    
    http://www.jkp-ads.com/articles/apideclarations.asp