how to prevent mouse grab while debugging 3D application on a java IDE?

3
votes

Most 3D applications grab the mouse. This means the OS cursor is hidden and only the 3D application cursor is shown (and only within the application).
In case it is a game, the cursor is completely hidden so you can "look around" moving the camera with the mouse.

While I am debugging with Eclipse IDE or NetBeans IDE, the "grab mouse" event happens.
When a break point is reached, the application will not respond until, thru the IDE, I command it to continue running in the debug mode.
If I manage to make the application continue running I can release the mouse (un-grab, give back the mouse cursor to the OS) by opening a console within the application for example will make it work.

While I have no OS mouse cursor available, I get limited to the keyboard, what make things become really complicated on debugging procedure.

how to work around that?

1
javadebuggingmouse
I did not receive an email saying my question was on hold... by chance I looked here and found out; if passed 5 days it would be closed without I knowing? - Aquarius Power
I explained very basic things that I understand programmers are used to. Was it too much or unnecessary? Only did that because of the "on hold"... - Aquarius Power
Your edit appears to make this into an implementation / IDE tooling issue (which at least I was unsure of before). You may wish to flag this for migration to Stack Overflow where it could be on topic. - user289086
@MichaelT, mmm.. indeed, this is not a specific programming problem but an IDE issue! ok I will flag it, thx! - Aquarius Power
Possible duplicate of LWJGL grabbed mouse - debug if application hangs - barteks2x

1 Answers

3
votes

I found that a simple trick must be used.

Add a watch that evaluates this:
org.lwjgl.input.Mouse.setGrabbed(false)

On eclipse, that watch may require to be visible or its evaluation may be skipped.

here I am looking for an IDE independent way of ungrabbing mouse.

Doing more things than releasing mouse grab:

Later on tho, it did not suffice, I wanted to do more things like auto pause the application and clear keyboard buffer, so, if the breakpoint or exception happens at any code that have no access to the function I created that does it all, that function would not work.

The workaround for that was to create a thread to monitor some variable that should be updated at the main application thread; if that variable is not updated for 1s, call the function to ungrab and etc.