🚀 go-pugleaf

JD wrote:

>Using client relative v/s screen relative makes no difference
>because the difference between the old position and the new
>position is the same regardless of what variables are used to
>calculate it.

Um, but not if it is using box-relative.
As you move the bar left, the box moves right.

Let's run some numbers.
Listbox is scrolled right to max by 50 pixels.
Seperator bar is at 100 in the client window (150 listbox-relative)
Seperator bar remains stationary.
Left half of table is message info, right half is after application of
message.

Event	box at	mouse at	         Delta   box goes to  mouse at

Click	-50	100 (150r)	0	-50	[150r]
Drag	-50	99 (149r)		1	-49	[148r]
Hold	-49	99 (148r)		1	-48	[147r]
Hold	-48	99 (147r)		1	-47	[146r]
Drag	-47	98 (145r)		2	-45	[143r]
Drag	-45	97 (142r)		3	-42	[139r]
Drag	-42	96 (138r)		4	-38	[134r]
Drag	-38	95 (133r)		5	-33	[128r]
Hold	-33	95 (128r)		5	-28	[123r]

The problem you are trying to solve is the large delta.
You want it to be 0 or 1 in all these instances.
Look at the move in the last line.
If you remember the screen coordinate of 95, you would see 0 movement.
If OTOH, you remember the box-relative 133, and now you see
box-relative 128, you see a movement of 5.

Since you are processing WM_MOUSEMOVE, the mouse coordinates are in
listbox-relative coordinates (the fast-changing ones).
You might try remembering/comparing ClientToScreen(msg point) values.

Or, remember the mouse position _after_ the resize with
GetCurrentPos() and ScreenToClient(),, and compare directly to the
next message.

I'm thinking the first method (ClientToScreen) would work in all
cases, right, left, maxed or not?