7 replies to this topic

[AHK Johns]

Currently, ImageSearch command accepts file name as target image to search (needle) argument. Because of this, I have to create or use external image file to find matching image on screen. I'd like to use more generalized functionality, like using HBITMAP handle or memory buffer with BMP image data as target argument.

 

And please add simple function that converts JPG or PNG image from file or memory buffer to HBITMAP handle and function to scale it to certain size. It may be one of the most requested feature of AHK, I guess.

 

RegionGetColor ( http://www.autohotke...ndow-v38-mcode/) without using MCODE would be another great help. I can  not use MCODE in my computer due to NX bits. So I have to use separate DLL version of it.

[guest3456]

you may want to check out this thread which uses the GDI+ library:

http://www.autohotke...ip-imagesearch/

although that contains MCode as well. i don't understand NX bits but you can give it a try

[AHK Johns]

I think that the idea I suggested might be implemented very easily. All the commands or functions that take a image file name can simply work with HBITMAP handle  number without much work.  I looked the source code of AHK_L in Github. It seems that  "LoadPicture()" function in util.cpp loads all the images from file.

 

So, in "LoadPicture" function, add check for the file name like "ahk_handle 123456"  form, which is not valid file name obviously. Then just parse the "123456" part (may be hexa decimal, too) into integer and cast it as HBITMAP handle and return it as return value of LoadPicture function. It won't take much  source code change. The "ahk_handle" may be omitted, too.  Just simply, if the file name is  pure interger string(decimal or hexa) without no dot(period character) in it, it is very safe to assume that it is HBITMAP handle number and not valid file name. Just add following code in LoadPicture function.

unsined h = strtol( Filename, NULL, 0);
if ( h != 0 )
 return ((HBITMAP) h);

Then, all the function and commands that takes image file name argument will work magically with HBITMAP handle, too,  specified in forms like SearchImage, ,,,,, %hbmp% . It will open endless new utilization idea and possibility for such functions and comamnds. 

 

And add  new function that takes a (picture) file name or a variable with memory buffer (with VarSetCapacity) with picture image data in it as its argument and return a HBITMAP handle from it. Then it will open many new programming possibility for handling image files.

 

 

How about that?

[AHK Johns]

More suggestion. I tried some experimental implementation of above idea and found that it is even better and useful to use resource id as source of image.  So I revise my suggestion like be low. For any commands or functions that takes image file name as its argument,

1) if the filename starts with preceding "#" char, it is resource number or name. with optional resource type name (like "PNG" or "GROUP ICON" or  any pre-defined resource type numeric index), the image is taken from default resource module/file. (%A_ScriptFileName%".EXE" for compiled script, %A_ScriptFileName%".{RES, DLL }" for non-compiled script.    For example : "#1234, ICON" "#MYPIC, PNG" , Or optionally resource module may be specified in the name.

2) If the file name starts with preceding two consecutive "#" characters, it is HBITMAP handle number like "##0x123ab345"

3) Else it is normal file name

 

Any opinion?

[AHK Johns]

I finished the code that implements the proposal I made above.  Where can I contribute the code? I don't want to put it directly to github source tree of AHK_L before seeing more interest on such feature. Is there any other interested in such feature?

[guest3456]

I finished the code that implements the proposal I made above.  Where can I contribute the code? I don't want to put it directly to github source tree of AHK_L before seeing more interest on such feature. Is there any other interested in such feature?

you can initiate a Pull Request on github, and then Lexikos can review your code and see if he thinks its sufficient for including, or if he thinks that there isn't enough interest. he would still need to approve it

personally, the GDI+ ImageSearch that i linked to is very fast so I would prefer to just see that ported into the main AHK code instead. then you can use the GDI+ library written by tic which is very comprehensive (and includes your request for memory HBITMAPS)

[AHK Johns]

you can initiate a Pull Request on github, and then Lexikos can review your code and see if he thinks its sufficient for including, or if he thinks that there isn't enough interest. he would still need to approve it

personally, the GDI+ ImageSearch that i linked to is very fast so I would prefer to just see that ported into the main AHK code instead. then you can use the GDI+ library written by tic which is very comprehensive (and includes your request for memory HBITMAPS)

 

One of  the  intent of my suggestion is to abolish explicit use of GDIPlus or GDI+ AHK library to do relatively simple task that does not require full strength of  GDI+. GDI+ is great library but it is too much for doing mostly simple tasks.

Just loading PNG image from resource or embedded data string and doing image search with the image should not require explicit use of GDI+, IMHO. The AHK itself already has enough power comparable to  GDI Plus in handling PNG file or resource. 

[golpebaixo]

This is a very interesting feature.
How`s it going?