ThinkGeo.com    |     Documentation    |     Premium Support

OnMouseClickCore in edit interactive overlays

I have built a couple of EditInteractiveOverlays.    I have implemented OnMouseClickCore overrides to the base class.  However, they are never called.    I have also implemented DrawCore on those same classes and those methods are called.    I do not have any shapes in the EditShapesLayer.      Is there anything else that I should look at to ensure that the Mouse*Core methods get called?



Ted, 
  
   So you are not getting the click called on any of the custom overlays you built?  A few things to keep in mind, when you override the methods like the mouse click you need to make sure that if you do not handle the event with that overlay that you return that you did not handle the event.  To do this make sure the ResultsClass that you pass back returned true in the InteractiveResults.ProcessOtherOverlays.  If one of the overlays you created passes false through that property then it will stop the other overlays from getting the mouse clicks.  I don’t think this stops them from drawing though.  This is the first thing I would check and be 100% sure about.  One way to test this is by a break point but also you could remove all of the interactive overlays and see how one of your’s does when it is the only one. 
  
 David

Ted, 
  
   One other thing to remember about the click event is that it only gets called on a real click.  I mean a mouse down and a mouse up in a specific period of time.  It is a bit different then the Winforms version.  We also check for double click separately so if the user double clicks you should get one double click event but not two click events.  We wanted to intelligently handle this as this always drove me nuts in every Winforms application I ever built. 
  
 David

I've spent most of the afternoon on this... and at some point, the MouseClick did start firing.    And then I couldn't figure out how to get it not to fire when I would click on the resizing control, relocating control, etc.


I finally realized that the MouseClick was not the event I wanted :(    The MapClick is the right event.   It will not fire when you click on the resizing handle, etc.   It only fires if there the use of the mouse serves no purpose in an interactive overlay, apparently.    that is what I was looking for.   I wanted to select a shape to put it into the editor, but not be selecting shapes again when a person click on an editor control.


It just took me a long time to recognize the difference between Chen's code that worked, and mine that was getting loaded up with all sorts of flags.


I think I've got it now... anyway.



Ted, 
  
   Glad you got it figured out.  Yea the order of the overlays is important as they handle the events in that order.  Also if one interactive overlay things you are talking to it then it will ‘steal’ the event and may or may not raise it up.  This was put in to stop multiple overlays from thinking they all have to respond.  If you click on a control point and drag it we don’t want the panning to happen , you know what I mean.  We also like you to work with the MapClick or Mapxxx events as we pre-process them and only raise them when it makes sense, as I went over in the previous post.  We are going to be adding a keys type of event soon so you can process keyboard key presses etc to things like undo with escape key and arrow key stuff.  Also one thing that is cool is that with our own events it is possible to fire them without any mouse at all.  It will be possible to just create an event that happened say a mouse click and feed it through the system and it responds to it even though it didn’t really happen.  I am not sure how we will use this but it has been on my mind.  I think things like testing or using keys to do things like pan or keys to do mouse clicks etc… 
  
 Sorry you had to spend more time on this then maybe you should have but once you get it down it is a really powerful system.  I have a feeling you are going to push it to the limits. :-) 
  
 David