none
Single workbook to run in both 32-bit & 64-bit Excel. RRS feed

  • Question

  • Hello,

    My Excel application  works as a GUI  for an engineering software. It's a  .xlsb workbook with numerous user forms and modules that works in all Excel versions.

    Since some of our clients use 64-bit Excel, while majority is still on 32-bit Excel, I always maintain two different workbooks.

    But recently more and more companies are "in transition" - they have "rolled out" 64-bit Office on some computers, while others are on 32-bit Office. To avoid confusion for our users, I decided to create a single workbook to run in both 32-bit & 64-bit Excel.

    I added  "#If VBA7 Then " for "Declare" statements, used LenB(OFN) when needed, had "BrowseForFolder" that works for both Excel versions, etc.

    We have been testing this single workbook and it seems working fine. But it's a limited testing.  

    My question to people who have experience with creating 32 & 64 applications - do you see any potential problems when single workbook is running  in both 32-bit & 64-bit Excel

    I consider recommending them NOT to save the workbook on 32 and then open on 64 (and vice versa), but is there anything else I should be aware of?

    Thank you!!!

    Julia

    Friday, March 6, 2020 8:31 PM

Answers

  • In theory yes, one version of the workbook should be safe for all users, subject to the caveat I mentioned about general backwards compatibility. If you're only catering for 2010 and later you don't even need to include include the VBA7 conditional compiler constant. You might need the Win64 with a handful of APIs.

    Just keep in mind that pointers and window handles will be 8 bytes (LongLong) in 64 bit and 4 bytes (Long) in 32 bit, I expect that's where your LenB is needed (size of a Type that includes a LongPtr perhaps). You can see these where a LongPtr is given in PtrSafe API declarations, LongPtr is in effect a LongLong in x64 and Long in x32.

    Also be sure to declare any variables in your code that pass or receive a 'LongPtr' to/from any API where declared as LongPtr, either as the return value or as an argument.


    Monday, March 9, 2020 2:52 PM
    Moderator

All replies

  • If you've fully adapted and tested your code to run in 32 & 64 bit versions under #If VBA7 (incl any special differences for 'Win64' only), and if catering for 2007 or earlier in 32bit but not under VBA7, normally there should be no problem saving and exchanging workbooks between 32 and 64 bit users. That is, assuming the workbook is backwards compatible irrespective of 32/64 bit.


    Monday, March 9, 2020 12:34 PM
    Moderator
  • Peter, thank you for the reply!

    We don't have users on 2007 Excel. Only 2010 and up; most of the users have 365 subscription installed by IT.

    So, do you think it is safe to release a single workbook to run in both - 32-bit Excel and 64-bit Excel?  

    Regards,

    Julia

    Monday, March 9, 2020 1:19 PM
  • In theory yes, one version of the workbook should be safe for all users, subject to the caveat I mentioned about general backwards compatibility. If you're only catering for 2010 and later you don't even need to include include the VBA7 conditional compiler constant. You might need the Win64 with a handful of APIs.

    Just keep in mind that pointers and window handles will be 8 bytes (LongLong) in 64 bit and 4 bytes (Long) in 32 bit, I expect that's where your LenB is needed (size of a Type that includes a LongPtr perhaps). You can see these where a LongPtr is given in PtrSafe API declarations, LongPtr is in effect a LongLong in x64 and Long in x32.

    Also be sure to declare any variables in your code that pass or receive a 'LongPtr' to/from any API where declared as LongPtr, either as the return value or as an argument.


    Monday, March 9, 2020 2:52 PM
    Moderator
  • Peter, thank you for your reassurance and advice!

    Regards,

    Julia

    Tuesday, March 10, 2020 5:05 PM