[sldev] [VIEWER] Bug/inefficiency in mouse-handling in LLScrollLIstCtrl and other GUI classes?

[Lawson English]

Lawson English wrote:
> Lawson English wrote:
>> I've been trying to implement my baby hierarchy/outline list class 
>> and I found that "handleClick" to scroll list cells didn't pass the 
>> x,y,mask values to the cell. This is required in order to do things 
>> like drop-down folder arrow-icons, or  edit-text-in-place cells, so I 
>> added the parameters in in the relevant places and dumped the x/y 
>> values to the debug console.
>>
>> The result suggests that handleClick is called over and over again on 
>> a single click, even though only one x/y value is passed down the 
>> line. This is inefficient, and probably reduces framerate, and 
>> possibly has other side-effects as well. The shortest click I could 
>> manage called handleClick 9 times.
>
> I am confused about this though. if handleClick is called multiple 
> times, it should cause things like LLScrollListCheck::handleClick
>
>
> to be called multiple times which should set/reset checkboxes over and 
> over.
>
> Testing...
> _______________________________________________
LLScrollListCheck doesn't receive multiple handleClicks. Nor does my 
code IF it is does something else involving mouse handling that takes 
any significant time after the first click is received. The 
multiple-call seems to occur only if a do-nothing handleClick function 
receives the message with no intervening code of any significance.

My intuition suggests that this is a sign of a hidden inefficiency, but 
it DOES APPEAR to  allow one to work with the code without  fear of 
getting multiple clicks. Depending on latency to prevent multiple calls 
is a bad way to code. There may be other issues that prevent the 
multiple handleClick calls, but latency appears to be a factor.

L.