🚀 go-pugleaf

Bob Gonder <notbg@notmindspring.invalid> wrote:
>
> What I observe is this. [...]

I saw the same but hadn't noticed that behavior until I tested
it with Windows Explorer.

> I'd leave it alone,

I don't think that I can because when running my code, even
though it behaves the same, it's much more dramatic because
I've optimized the drawing to eliminate flickering. Even worse,
If the scrolled area is large enough, it will collapse a column
entirely in the blink of an eye.

> limit mouse movement to 1 or 2 pixels (limits shrinking to
> one or two pixel speed)

This isn't possible. I logged the messages and there getting
processed on a per pixel basis. Sure there were a couple that
slipped through that were multiple pixels but they required
effort on my part to effect them.

> reset mouse to bar. If mouse moves faster, box shrinks
> faster. If mouse stops, box stops.

At this point, I'm thinking that the mouse is going to have to
be repositioned but I *really* don't wanna do that.

> Third option would be to somehow remember last mouse
> position, and only reduce the box by the delta rather than
> the absolute.

I'm not sure what you mean by this. The code currently saves
the click point, makes the size change and then updates the
click point to the current point. The change in size is
calculated by comparing the click point to the current point.

What the ultimate problem is that when the column size changes,
the scrollbar is affected which causes a redraw because the
window is no longer scrolled to that position.

If the mouse it at 100 and moved to 99, after that one pixel
move has been processed and the window is redrawn, the mouse
is now at 98 even though it wasn't moved! (your observations
seem to confirm this).

I'm hoping that it's just a not-so-simple logic problem that
another pair of eyes can see.

~ JD