Problem running compiled script using Excel.au3

[mrwilly]

Hi all,

I have a script that opens an Excel file. It works fine if I run it as a script, but if I compile it then it only works if I run the compiled script as administrator. If I run the compiled script as a normal user I get an error saying "The requested action with this object has failed".

In fact, the following basic script has the same problem:

#Include
_ExcelBookNew()

Any ideas on why this happens?

BTW, I'm running AutoIt v3.3.8.1, on 64-bit Windows 7, with Excel 2010 64-bit.

[water]

The problem might be caused by the 64-bit version of Excel.

Even Microsoft doesn't recommend to use the 64-bit version of Office.

Can you test somewhere with a 32-bit version? If yes, make sure to compile the script for 32-bit even when the OS is 64-bit.

[mrwilly]

Thanks, I'll give that a go in the morning (1am over here).

If that's the problem then there might not be much I can do as we need the 64 bit version of office for some of our work (clunky I know).

[water]

If it works with the 32-bit Office the next thing to try is to use the native Excel COM (without the UDF). The UDF is quite old and might have problems with 64-bit versions.

[mrwilly]

Well, it does indeed work fine with the 32 bit version.

I tried the following:

$sFilePath = "C:\test.xlsb"
$oExcel = ObjCreate("Excel.Application")
$oExcel.Visible = 1
$oExcel.WorkBooks.Open($sFilePath, Default, 0, Default, Default, "m")

This works fine with 32 bit Excel, works from a script with 64 but Excel, but fails when compiled with 64 bit Excel.

Is this what you mean by using the native Excel COM? I tried looking around but couldn't find anything that suggested otherwise...

[mrwilly]

I added a COM error handler I found on another post, and got the following out: "Microsoft Excel cannot open or save any more documents because there is not enough available memory or disk space".

Sounds weird...

[water]

Is this what you mean by using the native Excel COM? I tried looking around but couldn't find anything that suggested otherwise...

Correct

[water]

I just noticed you try to open a XLSB type of file. Could you try to open an ordinary XLSX type?

[water]

Something else that comes to my mind: Have you tried to compile with the latest beta version?

[mrwilly]

Ok, it's now working, but I only sort-of know why.

It appears the problem is to do with permissions.

If the script is sitting on my desktop and I copmile it, when I run the .exe it gives me a "The publisher could not be verified. Are you sure you want to run this software?" message. If I click "Run", I get the error.

However, if the script is sitting in the root folder of my C drive and I compile it, the resulting .exe doesn't give me the message about the publisher not being verified. It just runs (correctly).

Is the .exe inheriting some odd permissions from my desktop folder or something do you think? I imagine this is probably obvious to somebody

[water]

That's what is called "Trusted locations". You only start programs from this locations. Here they are set by our security policy.

[mrwilly]

Ok, cool, I'll chat with our admin about what locations are trusted on my PC.

What I find interesting is that if I compile in a trusted location, the .exe will run from anywhere. So it's important where the .exe is compiled, not where it's run from.

Anyway, thanks for your help!

[water]

Glad to be of service