Mouse selection lost when scrolling

[GoogleCodeExporter]

What steps will reproduce the problem?
1. put text enough to scrollbar appears 
2. begin text selection, then move mouse up (or down) (don't release mouse 
button!)
3. when scrolling occurs, selection will be lost (or screwed up)

look at http://code.google.com/p/olog/ for good solution

Original issue reported on code.google.com by [email protected] on 15 Nov 2010 at 11:32

[GoogleCodeExporter]

Original comment by [email protected] on 15 Nov 2010 at 11:47

• Changed state: Accepted

[GoogleCodeExporter]

'Fixed' for 2.5 (branches/2.5beta)
This issue will still be there if you have a lot of lines and you start 
selection from near the top of the scroll, dragging to bottom.
This is because while you are viewing the bottom page, it does not print the 
rest of the text above, for faster rendering. 
This should be a much rarer case which I don't think is worth considering.

Original comment by [email protected] on 15 Nov 2010 at 10:04

• Changed state: Fixed
• Added labels: Milestone-Release2.5

[GoogleCodeExporter]

Please take a look at this small video [784 Kb]:
http://www.astonshell.com/tmp/flash_console_bug61.avi
199-160 = 39 == a lot of lines?

Original comment by [email protected] on 23 Nov 2010 at 11:56

[GoogleCodeExporter]

Yes this is the unfixed part of problem that I mentioned. If you selected from 
bottom going upward you'll find that it worked.

The reason is because as soon as you reach the bottom of scroll, console 
redraws the TextField with lines just enough to safely cover the visible area. 
(in your case it was line 182. 17 lines). This is so it prints updates a lot 
faster.
I'll check olog how they handle this.

Original comment by [email protected] on 23 Nov 2010 at 8:17

• Changed state: Accepted
• Removed labels: Milestone-Release2.5

[GoogleCodeExporter]

Just tested on Olog
It keep all logs drawn on TextField so it doesn't have this issue. But the down 
side of this is that it's not as fast on adding new lines.

To prove my point this is what I tested just now:

var timeNow:uint = getTimer();
for(var i:int = 0; i<500; i++){
    Olog.trace("LINE:"+i);
}
var timeTaken:uint = getTimer()-timeNow;
Olog.trace("timeTaken "+timeTaken);
// timeTaken 9210 ms
____________
Console:
var timeNow:uint = getTimer();
for(var i:int = 0; i<500; i++){
    Cc.log("LINE:"+i);
}
var timeTaken:uint = getTimer()-timeNow;
Cc.log("timeTaken "+timeTaken);
// timeTaken 7ms

I'll keep this issue open while I look for a solution without speed compromise.

Original comment by [email protected] on 23 Nov 2010 at 8:36