C# Mouse handling / forms

So I'm new to C# and have done a few gamey projects as learning exercises.

One I'm currently doing is a sort of practice run at an RTS. It's VERY basic stuff.

I have a commandbutton that builds tanks; said tanks are instances of a class that contains a picturebox.

Said tanks can be moved around by left clicking anywhere on the form where there isn't another control.

Said tanks can also fire a shell at a random place on the form by right-clicking, or specifically at another tank (i.e. if the target tank moves, the attacking tank will adjust it's aim accordingly).

The problem I'm struggling with is selecting multiple tanks.

I'd like to do this via a开发者_如何学Python rubberband selection (i.e. you drag a rectangle over the tanks you wish to select).

I've tried numerous ways of handling the various mouse events; ideally I'd like it to be timer-based so I can also deal with multiple key presses etc, but at the mo I'm only able to do it using MouseUp, MouseDown, and MouseMove events coz the timer makes the rubberband a pain.

Problem is, these are only fired when the user clicks on the form. When the user right clicks a tank to attack it, nothing happens because the target tank's picturebox swallows the mouse events.

Can someone point me in the right direction here? Is there a way of intercepting the mouse stuff before it gets swallowed by the pictureboxes? Or just making the pictureboxes (bear in mind these are created at run time) pass the mouse event to the form?

Or am I looking at this from the wrong angle? Is there some better way of handling it?

Thanks in advance

You could use hooks if you really wanted to.

Here's one on mouse hooks

Here's one for keyboard hooks

You'd have an easier time, I think, with WPF because routed events travel along the entire hierarchy they are initiated in. Frankly, doing it in WinForms seems just like too much trouble for what it's worth.

Anyway, the way I'd do it would be to have all the objects register with some sort of event sink that can process events on their behalf; if the triggered event shouldn't be handled in the current state of the object, pass it on to the event sink and maybe route it to the proper place. The added complexity is a bit much, but that's the most flexible way I can think of.