That's a problem I'm also facing in my game right now. The GUI doesn't tell whether a mouse click has been handled or whether it went into empty space (the GUI knows this information alright, it just doesn't report it back yet).
I am considering several options currently:
One would be for the Screen to pass on input that the GUI didn't use (either with events or to another IInputReceiver that the game could register). This would allow the GUI to follow its behavior model (eg. if the user presses down a mouse button over a
control and moves the cursor away from the control, the input still belongs to that control until the user releases the mouse button again), but I fear it's too intrusive for the game - I want the GUI system to be something that can be added to a game, not
something that dictates the game's design.
Another one would be to let the input notifications (Screen.InjectMousePress() etc.) return a boolean that indicates whether the input was handled. This would also allow the GUI to keep adhering to its behavior model, but could be ignored by users not in
our situation who just want the darn GUI to work when the user opens the options dialog or whatever. The drawback here would be that it's a bit harder to integrate such selective targeting of input notifications when you actually need it.
You're doing it right, you just hit one of the areas where I'm still looking for the best approach. At the moment, the GUI keeps this information to itself, but there will be a way to get it soon, probably one of the two approaches above. If you have any
suggestions or input on this, I'd be glad to hear it :-D