Map takes focus on MouseEnter

Jan 19, 2009 at 6:35 PM
Edited Jan 19, 2009 at 6:38 PM
The current behavior on any MouseEnter event is for the map to take the focus. Is there a reason this is necessary? I tried removing that line of code and the map still seems to work fine. The focus stealing is a troublesome if you have a text box (like a search bar) over the map and most people's instinct is to click in the box, then move the mouse out of the way, which takes it over the map, and the text box loses focus!

Another side effect is that when using a MouseUp event (on a pushpin for example), unless you use CaptureMouse() in the MouseDown event, you won't get the MouseUp event.

Could the focus change instead be triggered on mouse button and wheel events? I tried this locally and seems to work well, but there may be side effects that I'm not aware of due to limited testing.

Richard
Coordinator
Jan 19, 2009 at 10:29 PM
This was added by smbecker a long time ago.  Here is his comment from a previous incarnation of this logic.  Perhaps he can fill us in.
                //TODO: Not sure why, but it seems that sometimes
                //there are issues with the keyboard events
                //not firing unless this line is here (smbecker:7/7)
Coordinator
Jan 20, 2009 at 8:55 AM
Yes in the first version we had issues with loosing focus for keyboard events, clearly this solved it by brute force. Time to remove it I think.
Coordinator
Jan 21, 2009 at 5:50 PM
This does look like a brute force approach.  However, I'd be surprised if the original issue actually healed itself.  So we want to be careful when simply removing that focus that we don't have a regression.  So the question is:  What is a correct fix to the original issue?
Coordinator
Jan 22, 2009 at 4:54 AM
Edited Jan 22, 2009 at 4:55 AM
Did some testing of what happens when call to Focus is removed.  When removed KeyDown does not fire ever for the Map when the SideBar is present and has focus.  It appears the default Windows Input controls swallow the KeyDown event from bubbling up.  This means navigating the map with the arrow keys and switching to "Zoom Selection" mode doesn't work. 

We should brainstorm potential fixes.  First we can change move to the call to MouseDown to reclaim focus.  This is still is imperfect as you would be required to click the map before Keys operate.  Perhaps there is a way we can centralize the event.  Is some way to leverage the FocusManager class?


Jan 22, 2009 at 2:38 PM
I think it's perfectly acceptable to have to actively return focus to the map, whether by clicking or using the mouse wheel. The alternative is that you make the rest of an application (the part that isn't the map) nearly unusable in some cases depending on how the user moves their mouse around when using the other controls.
Coordinator
Jan 22, 2009 at 5:28 PM
As already mentioned, actively taking focus is a good approach, but still might not the best approach.  Zoom selection will fail on the first try, and people will be confused as to why keyboard navigation with the arrows only works sometimes. 

As an alternative, I implemented an approach that uses the System.Windows.Input.FocusManager to get and set focus the previously focused Control on the MouseEnter, MouseLeave events.  Seems to be working okay.  I still open to an approach that would allow us prevent or bypass the standard Windows.Input controls from swallowing events.  Something similar to the old KeyPreview in WinForms or a way to centralize this event so that any control that needs it, gets it.