AutoHotkey Community

[holomind]

this version is with crosshair (diagonal) from the code from the other thread.

the problem was with missing h_pen.

you can also play with these values for color, style and size/margin of cross

[Trombonisto]

Hi holomind!

Sorry for my bad English and my incapability in AHK. But I want to do my best for improving my knowledge!

Just in time I found your new version. Thank you for all the time you spent for me! If you really want to try it with bitblt, please draw the crosshair upright and not diagonal.

And the poit of your crosshair is allways "between" the pixels but my destination is to find exactly the position of one pixel. So I need a crooshair "through" the pixel. Chould you change that please too?

To your question from today in the morning: No, I don't need a black crosshair. It only should be easy to distinguish from the background.

Thank you again and I wish a nice day. Trombonisto

[holomind]

[Trombonisto]

Hello!
Here is my version with a double crosshair.

[holomind]

[Trombonisto]

Hello holomind!

It took a while to twig that e.g. the R value already via parameter by calling the function comes into the function. Now I understand that a little better.

Meanwhile I changed the script in some details. I made a double cross for better finding the pixel. The crosshair is no longer offset the mousepoint in no zoom. I added Hotkeys for moving the mouse by the arrowkeys together with the Win Key.

For my purpose it is not good to keep the frame on screen so I deleted that section.

And I modifed the way to avoid the collision between magnifier and magnified area.

Here is my code:

[holomind]

hi trombonisto,

your script works quite good. also the red crosshair makes it easy to find the pixel.
my guess is that keywait, stops the whole script "while" this key is pressed.
and therefore it also stops the repaint of frame and magnifier.

one solution could be to have an hotkey to make mouse slow and another to make it fast. so you dont hold the key but only "click it" press+release.

another trick could be to unregister the hotkey "f9" so it does not get repeated calls. and re-register it when you press "f9 up".
on the other hand it would not hurt (perhaps only speed) to have set the SystemSpeedParametersInfo multiple times.
if windows is smart enough it will detect that the value is already 3 and not execute the write operation. (reads should be fast and writes should be slow)

or you do a manual "bugfixing" and save the state of the mousespeed, similar to the thing i use for toggle antialize on and off.

e.g.

[holomind]

just another idea to make it faster.
as you only draw horizontal and vertical red lines you can also do this with bitblt. setting color to red and using the rectangle for destination as the line. making it only one pixel wide or only one pixel high. using blitmode solid color. (or black).

[holomind]

now the idea of using bitblt to draw black lines applied.
(the lines go offset if you change zoom, i didnt understand the usage of M_C and R_C and zoom_c. so it does not adopt. i only want to show, how to use bitblt to draw lines (by copying black pixels from the DC to itself)
or in other words. fill a rectangle which is only one pixel high or wide.
perhaps this is faster as the drawline algorythm, as there is no need to detect the steps and angles. but lines are drawn by hardware-accelleration so one should not see a difference. also if the programmers implementing the line algo were smart they use bitblt for horizontal and vertical lines anyways.

one difference is that you can draw a line with one dll-call with drawline you have 2 dllcalls, one for move (define start) and draw (to define end).

you could make the cross even with less dllcalls (4) if you first draw the black cross (1hor 1 ver) and then repaint the inside of the cross not with copy-style solid but copy-style src-copy (frame2magnifiert) which needs more calulation for the right coordinates (you need strechblt and cant do it with bitblt)
bitblt: copy without zoom from src to dest. so you only define the start of src. (src-witdh/heihght are same with dest.w/h !)
strechblt: copy with zoom, so you define both rectangles src + dest for the drawing engine to know what to do.

after applying this change , the reactiontime was still slow, so maybe the drawline dllcalls arent so bad.

the problem was with your "optimization" of the move-magnifier.
in honor of lazlo i used supercompressed codestyle to move the window only when it changed. you removed this from your script and winmove (which is painfully slow) was called every repaint (and not only when it changes).
AHK is not smart enough to detect that the new position is the same and nothing is needed to be done. but on some posts in this forum this "bug" is used to force a repaint of the window calling winmove with old or no position.

so here my modified script:
* changed drawlines to bitblit draw horizontal vertial (note that this will never work with diagonal lines!)
* bugfixed the move-away function to make the script react much faster.

you can simply exchange the DrawCross function with the old one if you want your red lines back (which probably are not as slow as i suggested)

[holomind]

i remembered that the little frame also uses a lot of winmoves, which i learned is slow.

actually you dont need the frame (as you have your mouse there and the real value is small when you only want to find the right pixel.

so this version without any winmoves is really smooth, updating your zoomed area without noticable delay.

* this version is with red lines again,
* the #up etc. is compressed to oneliners
* little bit more comments inside code

[holomind]

with very little more code this could be made into a colorpicker, showing the colors in RGB and #HEXHEX for html usage.
with an hotkey to copy the targeted pixel-color into clipboard.

eg. (dont know if this works, may be black or white if it captures mouse-pointer color)
http://www.autohotkey.com/forum/viewtopic.php?t=11866&highlight=pixel+color+colour

[holomind]

[Trombonisto]

[holomind]

hi, sending keystrokes is not perfectly stable.

but this one works quite good for me

[Trombonisto]

Hi holomind!

Thank you again for all your help. That's really great!

No, I'm not working with imagemaps. I get graphs of mathematical functions (Kurvenscharen) and have to find the best fitting function. In the past I printed the PDFs out and took a simple ruler. That's a stone age method.

With help of the current script it is already much more easy and more precise. For me the script now works good enough but I thought about to give a compiled version to friends working at similar tasks. That's why I e.g. couldn't use .csv files, unfortunately.

To collect the coordinates seems to be a very good idea! But multidimensional arrays I couldn't handle, may be caused by the early time The help file isn't very helpful for working with arrays. And in the forum until now I only found one dimensional arrays.

BTW the livewindows script sounds good. I will try it - tomorrow. Good night

Tombonisto