When you press a mouse/cursor button down in something that receives events. When you SET CONSUMED on the event… you will continue to get mouse moved or cursor moved events to that original listener forever and ever and ever until the user releases the mouse button they clicked. No special tricks needed.
This is why the sliders still move up and down when the mouse is not over them. They are “captured” until the mouse button has been released.
behind the ResizablePanel there is a ListBox, with a selected item (this is the 1st animation frame!).
I click the ResizablePanel bottom border to drag it
fastly moving downwards, I release the mouse button, but what happens now is:
3.a) the resizing happens with the mouse cursor outside the ResizablePanel
3.b) the mouse button is released outside the ResizablePanel (because I was moving faster then it could be resized 3.c) the mouse button UP event is consumed by the ListBox behind it, so its item in the middle gets selected!
I further move the mouse cursor upwards. The CursorListener.cursorMoved() will continue receiving events, so my code will continue dragging it shrinking the window vertically (with the mouse button already released).
but, it is fully working now:
we can resize the window as fast as we want,
the drag hook will not be lost
the minimum sizes constraint will break the drag hook for safety
a direct LWJGL “mouse button not pressed” verification will break the drag hook, preventing further ResizablePanel resizing from the BuggyBehavior
So basically, the only remaining problem is the mouse cursor UP event is still sent to the ListBox, or anything else that could be behind the ResizablePanel.
it is working perfectly now, similar to any window manager border resizer out there!
removed the LWJGL check (of course).
The drag hook in a sense that the mouse is not at the border or corner while it still can resize the panel as long the button is pressed. Breaking it was to stop/end the dragging functionality. But with your latest tips, that functionality is only ended when the button is released, so no need to call it anywhere else.
EDIT: I just thought, instead of a ResizablePanel, it could be something that improves the existing Panel optionally, so I could use it with a Container or anything else, not sure if possible yet tho…
I wrapper panel is still probably the easiest/safest/clearest way.
In theory, you could so it in a special GuiComponent implementation.
Even still, the separate ResizablePanel thing is nice because it makes it easier to style the border and have that apply to all resizable windows in your UI.
A GuiComponent implementation could be added to GUI elements with styling… which seems cool at first until you think about the cases where it’s added accidentally and suddenly users can resize buttons and labels and stuff. Plus, it ends up being a wrapper for some other component that will actually draw the border.
Would be cool, took me a few mins to configure the whole project to run on eclipse, but I was too curious to see the demo
I will stick with eclipse Luna as it runs quite fast on my machine and I am quite used to it (to its minor problems too).