Mouse Temporarily Escapes from GZDoom - Dialogue

Need help running G/Q/ZDoom/ECWolf/Zandronum/3DGE/EDuke32/Raze? Did your computer break? Ask here.

Moderator: GZDoom Developers

Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!

If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.

We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
Post Reply
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Enjay »

I think this is more likely a technical issue than a bug. Indeed, it may not be either because I know that the dialogue system is actually a menu and so this behaviour may be expected.

I run a two monitor system (nothing unusual in that, but it lets me see the problem). Typically, if I am exploring files, I will have the relevant window open on my secondary monitor, and this includes if I have an Explorer Window open on my GZDoom directory. If I double click GZDoom, it will open on my primary monitor (all as intended).

However, what I have noticed is that if I open a Strife-like chat dialogue in game, the mouse click can get sent to explorer too. Typical example:

I drag and drop a mod with dialogues on to gzdoom.exe (which starts immediately in Doom2 because I don't have query IWAD set to true). So now what appears on my monitors is GZDoom on the main monitor and half of my desktop with a file explorer window open on the other. Everything proceeds as I would expect until I find a actor that can allow me to open a dialogue. I have secondary-click (right-click) bound to [USE] in game. When I press the [USE] button to open the dialogue (which happens correctly), a right-click event also gets sent to the Operating system.

So, as well as the dialogue opening in game, a context-sensitive menu opens wherever the mouse pointer was - this could be a file properties menu for whichever file the mouse was sitting over, the desktop properties menu etc.

Focus immediately reverts to the game, and the dialogue works as intended, but I now have a context-sensitive menu on my system just sitting there waiting for input. Perhaps the same thing happens on single monitor systems too, but can't be seen because GZDoom is in the way?

Is there any way to stop this happening?


Windows 10 64 bit - fully updated. Logitech G300 gamin mouse (drivers up to date) nVidia GeForce GTX 1080 Drivers also up to date. GZDoom running in full screen at 1920x1200.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by drfrag »

What happens when you right click while in the regular menus? Could you post a link to the mod?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Graf Zahl »

This sounds more like a bug in Explorer that it doesn't properly release the mouse capture when dragging & dropping in cases where its window focus is taken away by force.
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Enjay »

drfrag wrote:What happens when you right click while in the regular menus? Could you post a link to the mod?
Same deal actually - with vanilla (no mods). I never noticed it because I don't right click (or click at all for that matter) in the menus.

In fact, what I now notice (or rather, I noticed some time ago, but now realise it might be relevant) is that pressing Esc to call up the menu frees the mouse and the pointer appears as the default arrow wherever it was before I started GZDoom. Then, with the menu still active, if I move my mouse across from wherever it was (e.g. on the second monitor), as it moves from the explorer window/desktop/whatever to the GZDoom monitor, the cursor changes to the bunny-head and when I move the mouse back off GZDoom it reverts to the default arrow.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by dpJudas »

Enjay wrote:In fact, what I now notice (or rather, I noticed some time ago, but now realise it might be relevant) is that pressing Esc to call up the menu frees the mouse and the pointer appears as the default arrow wherever it was before I started GZDoom. Then, with the menu still active, if I move my mouse across from wherever it was (e.g. on the second monitor), as it moves from the explorer window/desktop/whatever to the GZDoom monitor, the cursor changes to the bunny-head and when I move the mouse back off GZDoom it reverts to the default arrow.
When GZDoom hides the cursor it saves its current location. Then it keeps recentering on the GZDoom window (while being hidden) so that any mouse clicking ends up being sent to the GZD window. When you press escape it moves the cursor back to where it was when it got hidden and is then shown. This ensures the cursor is always where the user left it. So in that sense this is doing exactly what it is meant to be doing.

If the strife dialog shows the cursor then that probably explains the buggy behavior. As you left the cursor initially outside the window, the position is saved, the cursor is hidden and centered on GZD. When you right click the mouse down event gets sent to GZD, it restores the cursor position and shows it. When you then release the mouse button the mouse up event gets sent to what is now below the cursor, which happens to be Explorer. It probably shows the context menu on a mouse release event.

There's two possible ways to fix this. One is to constrain the cursor position to be within the GZD window when it gets shown again. The other is to capture the mouse on press, because then it will send the release to GZD regardless of where the mouse cursor is released.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Graf Zahl »

The third option would be to switch mouse input to DirectInput which does not do this mouse centering stuff. I found this to be the least problematic input option by far. RawInput may be more modern but this centering bullshit really hurts.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by dpJudas »

Yes, there's always the option of not fixing a bug.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Graf Zahl »

I consider that entire mouse centering thing broken by design, so yeah, what do you suggest?
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by dpJudas »

Broken by design or not, solving things by using DirectInput is a dangerous thing to do. Like DirectDraw, the thing is in a legacy maintenance mode where it just barely works. I actually had to write a replacement dinput.dll for UT99 just to make it work properly on my system.

In any case, it doesn't seem to be rawinput's fault. At least I'm unable to reproduce what Enjay is experiencing with a simple raw input test program (see attachment).
Attachments
MouseTest.zip
(49.24 KiB) Downloaded 27 times
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by dpJudas »

I did a little more research on raw input. It turns out that the way we've been using it is not the correct way.

Raw Input can function exactly like DirectInput did, but it requires creating a separate hidden window with exactly the RIDEV_CAPTUREMOUSE | RIDEV_INPUTSINK | RIDEV_NOLEGACY flags. This captures the mouse in exclusive mode where no recentering is required. The main catch is that all mouse presses are generated as RAWINPUT events.

Edit: GZDoom already sets the RIDEV_CAPTUREMOUSE | RIDEV_NOLEGACY flags, so it doesn't have to do the centering at all.

I managed to reproduce the error Enjay is experiencing now. The problem is caused by the RIDEV_NOLEGACY flag. Whenever it is active the normal WM messages (WM_LBUTTONDOWN, etc.) aren't being processed, even inside Windows itself. The internal input state gets out of sync. For example, it sees the WM_RBUTTONUP message but never saw the WM_RBUTTONDOWN. Unfortunately the capture mouse flag doesn't work without the nolegacy flag.

My guess is that DirectInput is breaking in the same way, because it is implemented with RAWINPUT by creating a window on a worker thread with the same exact flags. Unfortunately the capturemouse flag doesn't work without nolegacy. Honestly this seems like a bug in the system that's probably been there for 20 years now soon.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by dpJudas »

I pushed a workaround fix for this thing. Also removed the need for centering the mouse when using raw input.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Mouse Temporarily Escapes from GZDoom - Dialogue

Post by Graf Zahl »

dpJudas wrote:I did a little more research on raw input. It turns out that the way we've been using it is not the correct way.
I can't say this comes as a surprise.
Regarding DirectInput, I've been using it for the simple reason that it works better than RawInput with the old code, deprecated or not. And the only reason I've been keeping it operational is that the RawInput version seemed broken to me. If you really got that fixed, I'll ditch the legacy input code - keyboard and mouse - immediately and keep DInput only for controllers.
Post Reply

Return to “Technical Issues”