On Windows GL, the game still collects/handles mouse events when the window is no longer active.

[SoundGoddess]

This seems like unexpected behavior. Try dragging another application window on top of your game window and then notice how in the background the game is still reacting to mouse events.

[Tzenchor]

That is the standard behaviour on XNA

[SoundGoddess]

No it isn't.

[SoundGoddess]

If I load up Stardew Valley and then open up a web browser window in front of it, SDV does not react to the mouse clicks on the web browser. That game is XNA4. If I load up a Windows/GL game and then open a browser window on top of it, the game reacts as if it was the selected window.

[Tzenchor]

I remember from my project having to add a check if window was active to avoid processing input.
Also I have just checked the the code I built for a manual test framework for monogame where I used components from the XNA project without the check and it is receiving and handling input (it is using the DirectX backend)

[kameko]

I think it's standard behavior for pretty much all game engines to do that. Like @Tzenchor said you have to manually check if the window has focus, and I'm pretty sure that's how all games work, Stardew Valley included. I remember having to check for window focus in a variety of engines and frameworks I've used for making games. It's really not a huge issue, it's just one little conditional.

[mrhelmut]

Game.IsActive is here for this kind of purpose (and probably what Stardew Valley is doing).

[SoundGoddess]

ok, thanks for clarifying :)

I still think that this is kind of strange behavior, and that you ought to have to opt in to it if you really need it for something instead of having it default this way. Could be named something like Window.AllowInactiveInputCapture that is set to false by default.

[mrhelmut]

The current MonoGame direction is to be faithful to XNA, for compatibility reasons. While additional features are welcome, default behaviors which differ from XNA are to be avoided (even if they have a positive impact on the original design), for now. At some point, MonoGame will take its own path, but that is not yet scheduled.

[SoundGoddess]

Gotcha, but at some point I'd say version 4 or 5 it'd make sense to change the namespace from Microsoft.XNA.Framework to Mono.MonoGame and then instead of a focus on legacy support the focus can be on what makes the most sense for the project.

[mrhelmut]

There has been a few discussions which tend towards your suggestion. #3306

[harry-cpp]

Mono.MonoGame

Mono and MonoGame are 2 completely different things.

[SoundGoddess]

Well I was under the impression that this was an extension of Mono project seeing as the github is set up under Mono's official github. But it doesn't really matter if we name it Mono.MonoGame or MonoGame.Framework or whatever else makes the most logical sense; my point was that calling it Microsoft.XNA.Framework ought to be deprecated at some point.

[dellis1972]

I think this is related #4924

[harry-cpp]

Not a bug.