[PATCH] Mouse wheel in minimap

[historic_bruno]

Mousewheel behaviors that work in the game view should work in the minimap as well:

1. Mousewheel up/down should change zoom
   
2. Shift+mousewheel up/down should rotate the view (like Q + E keys)

[historic_bruno]

Looks like perhaps this can be fixed by implementing ManuallyHandleEvent?() for CMinimap, and then handling a SDL_HOTKEYDOWN event much the way CGameView::HandleEvent?() does it.

[historic_bruno]

Of course it's not that simple. The GUI input handler runs before the hotkey handler, and currently it always returns IN_HANDLED on mouse events (even if the GUI object doesn't really handle the event), so there is no chance to handle these hotkeys. I'm considering changing the GUI input handler to always pass on mousewheel events or maybe changing HandleMessage? so it returns a bool value (true if the event was handled or false).

[historic_bruno]

Per discussion with Philip a few days ago, we decided that adding a Skip() method to SGUIMessage would be a good idea. GUI objects can then decide in certain situations to "skip" an event so it's not handled by the GUI, and thus gets passed further up the handler stack. Since HandleMessage?() currently expects const references, a bit of refactoring was required, and I cleaned up a few other things while I was there.

[historic_bruno]

Just going to upload this is a patch for now. Due to the refactoring, there may be some unintended consequences, although it seems to work fine for me. Basically any GUI object that wants to not handle an event should call Skip() on the SGUIMessage they receive. Also because messages are sent from several locations, the result will always need to be checked to know how to respond (continue processing the event or pass).

[Philip]

// TODO: Why mouserightdoubleclick script event not sent?
// TODO: Why mouserightrelease script event not sent?

I don't think there's any reason, they were probably just forgotten (in r3381).

Why have the no-script-event version of SendEvent (used in CInput::HandleMessage and CList::HandleMessage and CText::HandleMessage), rather than calling HandleMessage(msg) directly (like everywhere else)? It seems potentially simpler if SendEvent always does HandleMessage+ScriptEvent instead of sometimes only doing one of them.

The SGUIMessage constructors should use : ..., skipped(false) {} instead of : ... { skipped = false; } for consistency.

The Skip method comment could probably be clearer about the consequences of calling it and what "skipped" means (e.g. something like wxEvent's description: "This method can be used inside an event handler to control whether further event handlers bound to this event will be called after the current one returns. Without Skip() (or equivalently if Skip(false) is used), the event will not be processed any more. If Skip(true) is called, the event processing system continues searching for a further handler function for this event, even though it has been processed already in the current handler.")

[ben]

(In [9340]) Adds Skip method to SGUIMessage which works more or less like wxEvent.Skip: GUI objects can allow other event handlers to process an input event after they finish. Allows hotkey handling of mousewheel events after minimap. Fixes #673. Adds SendEvent? to GUI objects, used in place of separate calls to HandleMessage? and ScriptEvent?.