mrwilly

Brilliant, thank you so much!

Thank you! I did exactly what you suggested and it's working great. I'm actually using this as a way to call a custom URI scheme via an http link (by redirecting to the custom URI), because many apps don't support custom URIs (e.g. MS Teams). Ideally I'd like a way to respond to a GET request with something that causes the web browser to just give up and close the tab (and my AutoIt code can call the custom URI scheme). But failing that I think a redirect is probably the best I'll be able to do. It's just a shame that it leaves open a blank webpage in a web browser. Thanks again!!

I'm a bit late to the party, but this is awesome. I'm probably a bit slow though - how do I respond with 302 Found, giving a new URL to redirect to? I don't see how I can add a "Location" header to _HTTPAPI_HttpSendHttpResponse in my response. Many thanks!

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!

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

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...

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...

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).

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.