Hangs because of a missing comma!

Report problems with documented functionality
Rohwedder
Posts: 3091
Joined: 04 Jun 2014, 08:33
Location: Germany

Hangs because of a missing comma!

11 Mar 2020, 02:18

This script hangs because of a missing comma!

Code: Select all

q::pixelsearch, x, y, 8, 110, 325, 945  0x32FDCF, 50, Fast
guest3456
Posts: 3109
Joined: 09 Oct 2013, 10:31

Re: Hangs because of a missing comma!

11 Mar 2020, 10:08

so put the comma.

joefiesta
Posts: 377
Joined: 24 Jan 2016, 13:54
Location: Pa., USA

Re: Hangs because of a missing comma!

11 Mar 2020, 11:00

what a rude reply. The guy is trying to be helpful, pointing out something that is broken. Don't yell at him just because AHK does a crappy job of validating parameters.

Without the comma, 945 0x3e2fdcf is a coordinate. This parameter can be an expression, so it evaluates to 9450x3e2fdcf. Then, 50 becomes the color, and "fast" the variation. 50 is probably an acceptable color, but "fast" is not an acceptable variation value (which should be 0-255). So,at least two parameters are not validated. Errorlevel is set to 1 when the sample pixelsearch fails. His command should set Errorlevel to 2.
I disagree with the author about one thing: For me, the command does not HANG. It simply fails to find the color as expected. That is, it does complete.
Rohwedder
Posts: 3091
Joined: 04 Jun 2014, 08:33
Location: Germany

Re: Hangs because of a missing comma!

11 Mar 2020, 11:15

Try:

Code: Select all

pixelsearch, x, y, 8, 110, 325, 945  0x32FDCF, 50, Fast
MsgBox,% "ErrorLevel: " ErrorLevel
joefiesta
Posts: 377
Joined: 24 Jan 2016, 13:54
Location: Pa., USA

Re: Hangs because of a missing comma!

11 Mar 2020, 11:18

@rohwedder - you didn't read my post. I say what errorlevel is returned by the user's command. It is 1. I say "...when the SAMPLE pixelsearch fails ..."
gregster
Posts: 4470
Joined: 30 Sep 2013, 06:48

Re: Hangs because of a missing comma!

11 Mar 2020, 11:26

I can reproduce it. The msgbox (in the example two posts above) never shows here (v1.1.32.00).

I mean, failing silently is kind of on-brand for AHK in many cases, but hanging not so much.

But probably the search area is just getting too big... and PixelSearch doesn't like that (especially on a rather slow computer like mine):
https://www.autohotkey.com/docs/commands/PixelSearch.htm#Remarks wrote:If the region to be searched is large and the search is repeated with high frequency, it may consume a lot of CPU time. To alleviate this, keep the size of the area to a minimum.
Rohwedder
Posts: 3091
Joined: 04 Jun 2014, 08:33
Location: Germany

Re: Hangs because of a missing comma!

11 Mar 2020, 13:34

I wanted to know which coordinates the lower right corner of this pixelsearch will have. I tried:

Code: Select all

MouseMove, 325, 945  0x32FDCF
MouseGetPos, x, y
MsgBox,% x " " y
and got:
325 997 and a small preview window:
ahk_dass TaskListThumbnailWnd
ahk_exe Explorer.EXE
(I didn't know these windows before)
guest3456
Posts: 3109
Joined: 09 Oct 2013, 10:31

Re: Hangs because of a missing comma!

11 Mar 2020, 14:51

joefiesta wrote:
11 Mar 2020, 11:00
what a rude reply. The guy is trying to be helpful, pointing out something that is broken. Don't yell at him just because AHK does a crappy job of validating parameters.
the only thing broken is his code, not AHK. if you want AHK to give a warning, or validate that the coordinate is within screen bounds, or whatever, this is a wish list item, not a bug report.

OH NOES AHK HANGZ EVEN WITH A COMMA:

Code: Select all

 q::pixelsearch, x, y, 8, 110, 325, 100000000000000000000000000000000000000, 50, Fast

swagfag
Posts: 3763
Joined: 11 Jan 2017, 17:59

Re: Hangs because of a missing comma!

11 Mar 2020, 16:33

i have to side with guest. its not a matter of the comma not being there, its a matter of choosing by happenstance a huge ass search space. technically, it hasnt hung yet. eventually, the pixelsearch will finish and the script will move on - it will just take too long
User avatar
nnnik
Posts: 4461
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Hangs because of a missing comma!

15 Mar 2020, 02:49

This is clearly an undetected error.
Going by AHK v1 standards this should set the errorlevel when a parameter bigger than the screen size is passed along.
Saying otherwise is unhealthy for the language.
Recommends AHK Studio
Helgef
Posts: 4409
Joined: 17 Jul 2016, 01:02
Contact:

Re: Hangs because of a missing comma!

15 Mar 2020, 03:22

As has been noted, 945 is concatenated with 0x123 which yeilds 9450x123, the string to number conversion ultimately ends up with a call to the system's function _wtoi64 (on unicode builds), which yields 9450 from 9450x123, example,

Code: Select all

msgbox % dllcall("msvcrt\_wtoi64", "wstr", "9450x123", "int64") ; 9450
The program doesn't hang, it searches for the pixel on a very large area, in the slow mode, which will take a long time.

This problem is not unique for pixelsearch, for example, if you forget a comma for setkeydelay,

Code: Select all

setkeydelay 945 0x123
; when you meant
; setkeydelay 945, 0x123
msgbox % a_keydelay  "`n" a_keyduration ; 9450  "`n" -1

pixelsearch wrote: ErrorLevel is set to 0 if the color was found in the specified region, 1 if it was not found, or 2 if there was a problem that prevented the command from conducting the search.
The behaviour doesn't contradict the documentation. Ultimately, the bug is in the OP's code, which yields unfortunate results due to limitations of the implementation.

Cheers.
lexikos
Posts: 6878
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Hangs because of a missing comma!

10 Apr 2020, 21:27

The main reason for the "hang" is that the displaced comma causes slow mode to be used, and on modern systems, the slow mode is so terribly slow that it is probably always useless. For instance, I tried to PixelSearch my entire screen (which is a "modest" 1920x1080) with entirely valid parameters and time it for demonstration purposes, but I gave up on waiting for it to finish.

I read into this when I first moved to Windows Vista, and iirc, the issue is that each call to GetPixel on a screen context must:
  • composite all windows into one surface
  • copy that surface from video memory into system memory
  • return that one pixel the caller requested.
That's obviously, horribly inefficient. According to my testing at the time, it performed well enough on systems with onboard video, perhaps because the video memory was actually just system memory. I'm not sure if that's true on Windows 10. It also performed just fine when desktop composition was disabled, but I think Windows 8 and up are designed to have composition always enabled (even with only the "Basic Display Driver" installed).

If the conditions under which the slow mode becomes unusable can be proven (and can be programmatically detected), perhaps the Fast mode can be enabled by default in v1 without risk of breaking scripts. (It was not made the default when it was introduced due to differences in behaviour.)


Validation of numeric parameters would have avoided this issue (by alerting the author to the mistake), but as a general rule I will not add this type of validation to v1 due to the risk of breaking scripts. The lack of validation by PixelSearch seems inconsistent with the v2 policy, so could be considered a bug there even though the policy isn't explicitly documented.

Merely forgetting a comma in v1 may produce the same result while keeping the code technically valid: , Fast would be a legitimate way to specify a variable for the Variation parameter, which accepts blank values because it is optional.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 20 guests