Unsigned

AutoIt is written in native (unmanaged) C++ As for your problem, have you checked the .NET runtime version that you're targeting? VS2012 targets .NET 4.5 by default, but Windows XP only supports up to 4.0. You may need to change the targeted runtime in your project.

Yes. Yes. Yes. I can't say enough how good of an idea this is, I've thought the same thing ever since I discovered AutoIt.

Use this:FileDelete(@DesktopDir & "\Test Todd")

Firstly, use the [ autoit ] [ /autoit ] tags to post your code, its much more readable. That said, you do not need to FileDelete $search. It's a virtual handle to the search state, it doesn't actually reference an on-disk file. Just call FileClose to signal AutoIt that you're done with it. I'd also capitalize <File.au3>, but that's just me, Windows references local filesystems case-insensitively so it shouldn't really matter. What exactly doesn't work?

Hex editor. Replace DLL checksum. Or NOP out the check routine entirely.

DLL's can be disassembled. And even a web server check can be redirected through a quick HOSTS edit and a server on localhost (such as XAMPP).

The point was that it doesn't actually lower memory usage, just change the location at which those memory pages are stored. Windows will automatically page out as necessary if your physical memory approaches critical. Why cut your performance at all, for 10MB that you don't need anyway? If you did, it would already be paged out.

All this does is force Windows to page out working memory to the pagefile. It doesn't "free" any memory, and may in fact have performance hits for a running application, because it forces a hard drive access twice (once when you call it, once again when that page is needed again.) Windows will automatically do this for you if your free memory drops to critical. That's one reason why your machine is so much slower in those situations, because of all those page faults. The only situation this would be useful is in a long-running, little-executing process, such as a background service, that spends most of it's time sleeping. In those cases, this call acts as something of a "OK I'm idle, you can put my memory away to the hard drive until I want it again." Using this in a foreground application as a means to artificially keep the physical memory size down is just

Checking for what? Look at your code.

No. Your second example is wrong. Because you are using an array subscript $coord75[0] and $coord75[1] in the MouseClick() call, BEFORE you check. So if PixelSearch() does not return an array, you're screwed, and will get the "Variable subscript array blah blah" error. Data integrity checks come BEFORE you use the data.

AFAIK, he did recover it, with testdisk.

It would be helpful if you posted the final (working) call. That way if somebody else comes here looking for help on this topic, they can see what worked.

Edited/simplified the code. Hopefully you learn from it and don't just blindly copy/paste.

This is what you want. Explanation is in the comments since you seem to learn better that way. ; Loop forever (until we explicitly use ExitLoop) While 1 ; Do the PixelSearch() $coord75 = PixelSearch( 25, 150, 766, 534, 0x13D926, 0 , 1, "[TITLE:WindowLawl]" ) ; You must check @error immediately after the function that may have set the error; in this case, immediately after PixelSearch() ; Check $coord75 HERE as well, BEFORE you try to access it as an array in MouseClick() If @error Or Not IsArray($coord75) Then ExitLoop ; Now and ONLY now is it safe to call MouseClick() MouseClick("left", $coord75[0] + 15, $coord75[1] + 5, 1 , 0) Sleep(200) WEnd Sleep(100)

Maybe you could try setting up your home computer as an FTP server.

What exactly did you try with WinWaitActive? The fact that you're not even using the value of $coord1 makes me wonder if you really understand what the code is doing.

It's not so much the array size either, but loop performance. But hey, you don't have to take my word for it, go ahead and give it a shot Nothing like learning from experience. All the same, if I absolutely had to do image processing in AutoIt, I'd rip out a DLL or plugin to do the heavy lifting.

The everything-speed AutoIt is interpreted, and it's array performance is fairly good as such, but is not nearly ideal for image processing. And a decent screenshot would require a rather large array. Not saying it can be done, but it will suffer from execution performance. AutoIt is not an image processing language.

And what's the syntax of ttGetTitle? I don't see it anywhere in your original post. Your DllCall syntax is incorrect though, try this: $TitleName = DllCall($dll, "long", "ttGetTitle", "HANDLE", 1, "str", "", "int", 65536) Your "int" parameter is supposed to be the buffer size, not the string "Buffsize" The AutoIt "str" type allocates a minimum of 65536 bytes (64kb), so that should presumably be in your last parameter. Again, if you post the full syntax I can probably help you more specifically.

Can you edit your original post and fix the code blocks so they display properly? It would make reading it a lot easier.

I doubt AutoIt's performance would make this practical for anything other than very small images, but yes, the concept is solid.

So, as I understand it....you essentially want to be able to browse your home PC remotely, and retrieve files on the fly?

Yep. An alternate way is to think of it as X and Y coordinates on a two-dimensional matrix. But you've got the idea.

Pretty sure trying to manually mess with the Recycle Bin (other than through the provided API) is a bad idea. It does not store files in the same way that a "normal" folder does. This was the only official Microsoft documentation I could find on the subject, and it is over a decade old (only applies to Win98 and prior), and is no longer correct on modern systems (quick check on an XP system verified that.) FileRecycle() does not mean "move file to the Recycle Bin." Rather, it means, "do whatever the user wants done with a deleted file." And speaking as one who has the Recycle Bin disabled (when I delete a file, I expect it to be deleted!), I'd actually be pretty ticked off at any program that tried to second-guess me.

WinWaitActive may also be useful to you.