[SOLVED] _ExcelBookClose does not work for Office 2010

[water]

If I run the following script with my old Excel 2002 it returns "_Application".

If I run it with Excel 2010 it returns nothing.

As _ExcelBookClose relies on "_Application" it now does not close Excel but returns error 1.

Do you think this is a bug in Excel 2010 or in AutoIt?

#include <excel.au3>

$oExcel = _ExcelBookNew(1)
ConsoleWrite(objname($oExcel) & @CRLF)
_ExcelBookClose($oExcel, 0, 1)

Edited August 7, 2010 by water

[water]

I found a similar post titled "ObjName() return NULL" and ran the recommonded VBScript for IE, Excel and Word.

I get "IWebBrowser2" for the IE and "Application" for Word and Excel on Windows XP and Windows 7.

So I think the installation is OK.

Could there be a bug in ObjName with Office 2010?

[PsaltyDS]

The case is "_Application" with an underscore in the _ExcelBookClose() UDF, so that wouldn't match anyway if you get "Application" with VBS. But that doesn't explain why you get nothing from AutoIt ObjName(). Did you try any of the other ObjName() flags to see if any other attributes display?

[big_daddy]

I did some testing and this is what I found:

Office 2010 x32

• Windows XP Pro x32 - Works as expected
• Windows 7 Pro x32 - Works as expected
• Windows 7 Pro x64 - Same issue as OP

[PsaltyDS]

Did compiling 32/64-bit make any difference when running on Win7x64?

[big_daddy]

Did compiling 32/64-bit make any difference when running on Win7x64?

Good catch!

If I compile the code in 32-bit it works as expected on my Win 7 x64 w/Office 2010 x32

[PsaltyDS]

We need Water to roger up with his versions to see if his problem is the same. I was checking this out: TechNet: 64-bit editions of Office 2010

Edit: Also this:

Q. Why do you recommend the 32 bit version even when the OS is 64 bit Windows?

A. The main reason is app compatibility, which is why 32-bit Office 2010 is recommended even on 64-bit Windows. There are very few if any 64-bit add-ins for Office. For a more thorough discussion on the difference between 32-bit and 64-bit Office, please take a look at these docs:

http://technet.microsoft.com/en-us/library/ee681792(office.14).aspx

http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx

Ted Way [MSFT], Program Manager, Microsoft Office PLEX Enterprise Licensing, Group Policy, and 64-bit Office

* Marked As Answer byTed WayMSFT, ModeratorWednesday, November 25, 2009 10:03 PM

Edited August 6, 2010 by PsaltyDS

[big_daddy]

I think this pretty much sums it up:

ActiveX controls and COM add-ins ActiveX controls and add-in (COM) DLLs (dynamic link libraries) that were written for 32-bit Office will not work in a 64-bit process. As a result, Office 2010 64-bit solutions that try to load 32-bit ActiveX controls or DLLs will not work. Installations of 64-bit Office 2010 will run only 64-bit controls. Computers can have 64-bit and 32-bit controls installed, and Office 2010 64-bit can only run the 64-bit versions of the controls. The workaround for resolving these issues is to obtain 64-bit compatible controls and add-ins or to install Office 2010 32-bit (WOW).

[water]

Hi guys,

you are great!

That's exacly my situation: running 32-bit Office 2010 on 64-bit Windows 7.

I compiled my little test script for 32 bit and now I get the expected result.

The help file (Using Autoit -> Running under Windows 64-bit Edition) states:

"If you suspect that a script is not working correctly under x64 but it works under x86 then please report a bug."

Do you thing this should be reported as a bug?

Thanks a lot for your support!

Thomas

Edited August 7, 2010 by water

[PsaltyDS]

The help file (Using Autoit -> Running under Windows 64-bit Edition) states:

"If you suspect that a script is not working correctly under x64 but it works under x86 then please report a bug."

Do you thing this should be reported as a bug?

No, the problem was you compiled a 64-bit app to talk to a 32-bit COM provider (your 32-bit Office). I think the lesson there is to compile to the architecture of the COM interface you want to work with, not necessarily of the OS.

[water]

I was just wondering because the script jast ran fine up to the _ExcelBookClose function.

So there was no problem with the 32-bit COM provider. Only ObjName was not able to retrieve the name of the object.

Maybe ObjName could set @error and a bit of description could be added to the help file. This would make debugging a bit easier.

Without your help I would never have found the cause of the problem!

[PsaltyDS]

I think it will turn out to be a Microsoft bug/feature that the 64bit OS, running a 32bit COM provider under WOW64, doesn't return the name correctly to the 64bit API AutoIt uses when compiled that way.

But I could certainly be wrong, and there's no harm in submitting a BugTrac. That will at least bring the question to the attention of the Devs, who could answer it definitively.