Excel Module to Excel 64bit

[garylscott1]

My employer is unexpectedly force converting everyone to 64bit office applications.  I'm wondering if anyone has experience porting the IVF supplied module for interfacing to Excel for 64-bit compatibility (or if that is indeed necessary).  Any pointers appreciated.  Is the likly change limited to adjustment of address pointer sizes?

[andrew_4619]

You can still build and run 32 bit applications on 64 bit, it should not make any difference,

[andrew_4619]

Also read

 https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/733247

[IanH]

andrew_4619 wrote:

You can still build and run 32 bit applications on 64 bit, it should not make any difference,

64 bit excel requires 64 bit DLL's.

I'm not sure what the "IVF supplied module" referred to is, though  (COM interface stuff generated using the ifort fortran module wizard?)

[garylscott1]

I'm initiating excel via the COM interface and extracting data into my application using COM.  My question is what changes might be needed to the COM interface module.  I have a catch 22 situation.  You can only install either 32-bit or 64-bit excel on a single machine, not both.  So I don't yet have a machine to test it on.  My hope is that COM properly isolates the interface since it defines exactly the interface to be used, but maybe excel-64 doesn't honor that definition.  I understand that my application can be either 32-bit or 64-bit and that Excel itself provides its own 64-bit DLLs.  I know that as either a 32-bit or 64bit application, my application can communication with 32-bit excel just fine with no changes to the module.

[Eugene_E_Intel]

In don't know, what Excel does and how your application is structured, but typically, COM objects on the same machine could be used either as in-proc (same process) or out-of-proc (different processes, with COM providing IPC).  For in-proc usage, your COM object in a DLL would be loaded into Excel process and executed as part of that process.  In this case, your DLL must match the architecture used by the process (32 bit or 64 bit).  For out-of-proc usage, Excel runs in its own process, and your COM object is instantiated into a separate COM host process.  Since the processes are different, Excel could be 64 bit and your COM object could be 32 bit.  COM would provide IPC and marshaling, provided that the COM interface is properly defined.

[dboggs]

What is this "IVF supplied module for interfacing to Excel"? Since when? Did I miss a memo? Can someone point me in a direction to learn more?

Interfacing to Excel has long been on the wish list by many, and I thought I have searched for and read many discussions about it on this forum.

[andrew_4619]

dboggs wrote:
What is this "IVF supplied module for interfacing to Excel"? Since when? Did I miss a memo? Can someone point me in a direction to learn more?Interfacing to Excel has long been on the wish list by many, and I thought I have searched for and read many discussions about it on this forum.

Look at the AUTODICE sample supplied with IVF, that uses excel. 

[garylscott1]

Autodice, yes.  I adapted the associated module(s) to create a tailored subset (easier to maintain, and made the "more standard" by removing most IVF extensions.

My application (exe) calls procedures contained like:

call comInitialize(status)
call $Application_SetVisible(excelApp,.false.)
call $Application_SetDisplayAlerts(excelApp,.false.)
 

Once initialized and ready, I then extract data cell by cell (or a range of cells row by row for efficiency) into my application as a normal Fortran array.

I'm hoping it will just work.  I put out a call today for someone that's already installed Excel64 for a machine I can use for testing.

...signed "worried"

[garylscott1]

Amazingly, my com interface seems to work perfectly with Excel64 without change.  I was able to locate a machine with Excel64 to test on this afternoon.  This is a happy day.  Still suspicious though as is my nature.