Quote:
Originally Posted by greg nice
what bug is that?
the source isnt available at this time
Hi greg,
after a whole evening of testing i have finally found and solved the bug this evening.
Somewhere around line 830 ( that is, in version 1.21 ),
the code in this block:
Code:
if (DetectStarsAIs) {
.....
THIS CODE
.....
}
was causing trouble for me.
It sometimes marked a table as "all in detected" ( making it move to the table queue and thus making it popping up ) because it detected one of these 2 colors:
- 3FC0E7
- d3e8e
while in these particular cases, the colors should've been detected as 0x000000 ( the background ).
I checked why he sometimes saw these 2 colors and i have identified these 2 colors as the lightblue and darkblue edges of a Window in Windows XP.
I suspect that, when a table is being moved away ( or back ) to the stack, that the border goes over the pixel that is being checked. This pixel is not being detected as 0x000000 ( background color ) and therefore is being wrongfully detected as action-required.
I solved the bug for myself, by adding an extra nested IF-statement to this coding block, it goes like this:
Code:
if(pixel != 0x31737){ ; bug fix
; bug intercepted, the all in detection was a false alarm
}else{
DllCall("QueryPerformanceCounter", "Int64 *", CurrentQPC)
listAdd(tablequeue, CurrentQPC . "-" . A_TickCount . "_" . A_LoopField)
listDelItem(nonurgents, A_LoopField)
}
I use the color 0x31737 for this, because with my personal table sizes + at a
legimit all in detection, the color detected is always 0x31737
I've only did 1 testrun after this bug fix and it seems to be solved now.
However, i'll be 100 % sure of this after just a regular session of 2 hours.
I'll run such a full test this weekend.
That's all the information i'm capable of giving.
Maybe ( and probably ) you have better ways for solving this.
But for now, i'll have to stick with version 1.21
Last edited by Mercadiator; 03-03-2010 at 06:05 PM.