AutoHotkey Community

Open the script and read it. All are explained inside it.

What a great script. Saves me from writing all the DLL interface code, and works perfectly with no extra exe or dll downloads or installs.

Good job!

Thanks in advance to anybody who might be able to help me get to the bottom of this. I am using Sean's script to save a screen region to a file:

Behavior: no matter what the syntax, the image is always saved to the clipboard. After a few hours of troubleshooting, I think I have come close to where the problem might be, but I'm stuck now. Sean's script runs fine all the way to the point of conversion (the parameters are all passed just fine to that point), but it fails to identify the codec that it should use to save my TIF file. How do I know? Right after (Sean's original code):

... I captured the script variables, and got:

As you can see, pCodec, which is used later by gdiplus\GdipSaveImageToFile, is empty. I have no clue why and how to fix it, but I imagine with no codec identified, my TIF file cannot be saved... By the way, I can save the file as a bmp.

Any ideas anyone? I have given up...

I'm glad that you're determined to track the root of the failure yourself, especially in view of the fact that it's your first post, not merely said that the script did not work. BTW, you didn't tell what build of AHK you used, but I guess it's a 32bit UNICODE AHK_L from what you described. In fact, you're almost there why it's not working with UNICODE, there is a line in your quoted codes, Ansi4Unicode(). Yes this script was written for AHK Basic. However, if you're not using 64bit build, you can make it work with UNICODE with a few changes:
http://www.autohotkey.com/forum/topic18146-132.html

I already said this, but as the posts were deleted, I'd like to say it again. I'll leave the script as it is (for AHK Basic) until AHK_L becomes the default for the majority of the users. Then, I'll change it to the one (exclusively) for UNICODE AHK_Ls. Officially ANSI AHK_L will not be supported either. BTW, no, I'll not maintain multiple versions, only will keep one version, as that turned out to be even more confusing, observed often wrong matches between the script and the build of AHKs.

ha, leave it to the kreator himself to figure it out so quickly! I'm sure you're right Sean, I am using AHK v1.0.90.00 (the most recent one you can download from the ahk website) so the issue must be somewhere in Unicode. I will look into it, thanks for replying and for posting the link.

By the way, I think your script is really cool, even though I can't even understand half of it. And I'm not suggesting that you should create different versions, I think what you're doing by sharing it and offering free support is plenty of work, my hat off to you for that! Enjoy your weekend...

Spot on Sean, works like a charm now. Thanks again!

Sean, looks like I'm in too deep again... I finally figured out why tesseract doesn't like the tif files that I'm sending it: by default, gdip saves TIFF in LZW format. I dug around trying to figure out how to pass it a parameter for "compressionNone" when saving the file but I don't think I know enough to figure it out. You seem to be the definite expert in gdip around here, so could you please help me with this one also? I guess I just need to know how and what pParam to pass to

in Convert so that my TIFF is saved with no compression. And maybe this will help other people out-there.

Thanks a lot again.

I didn't implement parameters for TIFF. I think the code better be updated in order to support all possible parameters. Anyway, you can call it as follows for the moment

after changing the following code in the script
to

Sean, thanks for the extra code, unfortunately I wasn't able to make it work. All I got was an empty tiff file (0 size), even trying different parameters. Fortunately I was able to find a workaround using irfanView.

By the way, for anybody who needs to process further the ScreenCapture outputs, irfanView' command line options are awesome with AHK.

What's your OS? It works (using the 32bit UNIOCDE AHK_L) in my 64bit Win7 and GDI+ version 1.1. I can recall that the parameter exists even in XP and GDI+ 1.0, but, what I can't recall is that the parameter was actually working or not in XP. Although it's not a big deal as you found a workaround, I'm puzzled about 0-byte result as it implied non-trivial pParam was picked up. Can you tell me what are the results of the following codes each:

I'm even tempted to rewrite the GDI+ part via COM, assuming .NET is installed in every user's system, as the current codes seem to confuse users, even though I can see some parts would not appear elegant with COM.

Hey Sean, I think we had a bit of operator error involved in the process. I made the changes again from the original ANSI version to Unicode, plus these for TIF, and looks like it's actually working just fine. Sorry for my fat fingers, I think as I was trying to figure it out I made some changes that were not exactly correct, to put it mildly.

However, I seem to be running into a different issue: when calling CaptureScreen from an ahk file, it works fine (including uncompressed tiff). However, when running the ahk file through a Shell function from Excel VBA, I get the following error message:

Error in #include file "...ScreenCapture.ahk": Call to nonexistent function.
Specifically: StrGet(NumGet(ci,76*(A_Index-1)+44)), "." . sExtTo, "UTF-16")
Line#
218: DllCall("gdiplus\GdipCreateBitmapFromHBITMAP", "Uint", sFileFr, "Uint", 0, "UintP", pImage)
219: Else
219: DllCall("gdiplus\GdipLoadImageFromFile", "WStr", sFileFr, "UintP", pImage)
221: DllCall("gdiplus\GdipGetImageEncodersSize", "UintP", nCount, "UintP", nSize)
222: VarSetCapacity(ci,nSize,0)
223: DllCall("gdiplus\GdipGetImageEncoders", "Uint", nCount, "Uint", nSize, "Uint", &ci)
224: Loop,nCount
---> 225: if InStr(StrGet(NumGet(ci,76*(A_Index-1)+44)), "." . sExtTo, "UTF-16")
226: {
227: pCodec := &ci+76*(A_Index-1)
228: Break
229: }
230: if InStr(".TIFF", "." sExtTo) && nQuality<>"" && pImage && pCodec
231: {
232: DllCall("gdiplus\GdipGetEncoderParameterListSize", "Uint", pImage, "Uint", pCodec, "UintP", nSize)
The program will exit.

No changes either to CaptureScreen or the script calling it, the only difference is where the script is ran from. Does this have something to do with the ANSI/Unicode thing you think?

By the way, I am on XP Prof 2002 SP3, and Office 2007.

No, StrGet exists in ANSI AHK_L too. I think it's due to the remnant of AHK Basic (in registry). Looks like you used AHK Basic before coming to AHK_L?

I must have but I'm really not sure, I started with ahk about 6 months ago and I upgraded every time I noticed a new version.

I think I'm just not having luck with the Convert procedure, so I'll just save everything as bmp and then use irfanview to convert. Thanks for all your help man.

Greetings!

Ok... I do not know what I'm doing wrong.

first, i'm on XP sp3 so I have the gdiplus.dll already but when I run the following code I can get a screenshot copied to buffer but it never creates a file.



if i open MSPaint and paste I see that is does copy to clipboard

ScreenCapture.ahk is in the same directory as my script.

Read from the first post of pitiso above. I suppose the same symptom with you.