ThinkGeo.com    |     Documentation    |     Premium Support

Mode to lock map into panning even when mouse button is released?

#1

Our click-happy end-users frequently find themselves in a mode where the mouse movement pans the map even after releasing the mouse button. They must single-click or double-click the map in order to terminate the panning  mode.


I have added a ModeInteractiveOverlay (following the TrackZoomInWithoutShiftKey project) to replace the map's interactive overlay. I don't know if this interferes with the regular mouse interactions on the map (but will try testing without it to see if the problem occurs even without the interactive overlay replaced).


This causes significant confusion for the end-users, so your insights are greatly appreciated.



#2

One further clue. We inadvertently neglected to call the method CalculateAllControlPoints after clearing the InternalFeatures collection of the EditShapesLayer. By neglecting to call this method, might this leave the edit overlay in an unstable state? 
  
  
                 winformsMap1.EditOverlay.EditShapesLayer.InternalFeatures.Clear(); 
                 winformsMap1.EditOverlay.CalculateAllControlPoints() 
 

#3

Gregory, 
  
 Thanks for your post! 
  
 I got the ModeInteractiveOverlay, but can not recreate your problem. Please send me the code in Form_Load, I think it will be really helpful. 
  
 Thanks 
 James

#4

Sorry, my mention of ModeInteractiveOverlay was misleading. I think the core of the problem is due to lack of calling the CalculateAllControlPoints method. If we clear the internal feaures layer, but neglect to call CalculateAllControlPoints, does that have hidden side-effects?


I've remediated the code so that all calls to clear the internal features layer of the edit layer are paired with a call to CalculateAllControlPoints and so far it seems to avoid the problem of locking the map in panning mode, but I cannot be sure without full drunken monkey testing. Do you think I'm on the right track?



#5

Gregory, 
  
 The recommended way is call them together, that’s like our pattern. 
  
 I am not very sure it has hidden side-effects if you don’t call CalculateAllControlPoints method, I don’t have environment for testing because I am in vacation. I will tell you the result next Monday after I test it. 
  
 Thanks, 
 James

#6

James, don’t spend your time if you haven’t built out the test environment yet for this behavior. It’s enough that you say this is a pattern. We’ll just make sure our code follows the pattern; we can already observe the application behaving better, so I suspect that pairing the two calls has fixed our bug.

#7

Gregory, 
  
 Thank you for saying that.  
  
 So far, I have tested some cases and found a side effect that after you clear internal features, the control points still exists just you can not see them, but if your mouse down on the position of point and then drag, it will throw exception because the internal feature is invalid. 
  
 Please let me know if you have more questions. 
 James