ThinkGeo.com    |     Documentation    |     Premium Support

MapMouseMove in ExtentOverlay stops firing

#1

In upgrading to ThinkGeo 14 we have had to move some code into the ExtentOverlay, where we can override Mouse events that are no longer available in the map. We have written a custom ExtentInteractiveOverlay and it works fine most of the time. In the process of implementing a tool tip that pops up over the map where the mouse is positioned I noticed that sometimes MapMouseMove simply stops firing. I don’t know the cause but I did notice it seems to happen after I click on the map to select a feature, which is handled by the TrackOvelay. Any ideas?

Thanks!

Steve

#2

Hi Steve,

Please pull the latest 14.5.0-beta021 and

replace
mapView.ExtentOverlay.MapMouseMove += …
with
mapView.MapMouseMove+=

What was happening: ExtentOverlay.MapMouseMove is a per-overlay dispatch signal. It only fires when the dispatch loop actually reaches ExtentOverlay. Your TrackOverlay is configured to claim the event stream while it’s actively tracking (by returning DoNotProcessOtherOverlays from MouseMoveCore), which breaks the dispatch loop before it gets to your ExtentOverlay — so your handler goes silent until the track ends. This is correct for action events like MouseDown/Click, but it’s not what you want for a tooltip.

The fix in beta021: we’ve restored a proper MapView-level notification tier:

  mapView.MapMouseMove += (s, e) =>
  {
      // fires on every physical mouse move, before any overlay dispatch.
      // not affected by TrackOverlay / EditOverlay / etc. holding the stream.
      tooltip.Text = $"{e.WorldX:F2}, {e.WorldY:F2}";
  };

This fires synchronously on the UI thread before any InteractiveOverlay is dispatched, and is not affected by DoNotProcessOtherOverlays. The only precondition is that the map is initialized (CurrentScale > 0 and CenterPoint != null).

Same treatment has been applied to the whole family: MapMouseDown / MapMouseUp / MapMouseWheel / MapMouseEnter / MapMouseLeave / MapKeyDown / MapKeyUp. Use these for any observational UI (tooltips, status bars, hover highlights, coordinate readouts).

InteractiveOverlay.MapMouseMove (and its siblings) still exist unchanged — they remain the right tool if you specifically need the per-overlay dispatch signal (e.g. a custom overlay that wants to know when dispatch reaches it).

I hope that make sense, let me know if you see any other issues while upgrading.

Thanks,
Ben

#3

Ben,

Thanks for all your help. But couldn’t I just override MouseMoveCore in the TrackOverlay so that DoNotProcessOtherOverlays is set to ProcessOtherOverlays? That seems to work.

Thanks!

Steve

#4

Steve,

You’re right, that works — just know you’re flipping a broadcast flag. Every overlay after TrackOverlay (Extent, Edit, Adornment, anything you add later) will now receive mid-track MouseMoves. Today that’s probably harmless, but it’s easy to forget later when you add an Edit overlay or upgrade the SDK and something starts misbehaving mid-track.

mapView.MapMouseMove in 14.5.0-beta021 avoids that — it fires before overlay dispatch, so TrackOverlay keeps its “I own the pointer” contract and your tooltip still ticks. Same result for you, no audit burden later.

#5

Ben,

Thanks, that’s good advice.

Any idea when the 14.5.0-beta021 changes will be included in a production build?

#6

We are currently planning to release v15.0.0 in May, mainly alongside the ThinkGeo.GisServer release. This fix will also be included in that release.