ThinkGeo.com    |     Documentation    |     Premium Support

Map.Mode?

#1

Hey


I've been wondering how MapSuite 3.0 deals with different forms of user interaction using the mouse. In MapSuite 2.0 you had a Mode property on the map, which you could set to a number of options (Pan, Center, Selection, SelectFeatures, TrackCircle etc). I know the release email said that Drawing Track Shapes would be released later.


An example of what i'd like to do is be able to switch modes depending on what is under the mouse when I click. If there aren't any shapes, i'd like to drag the map... so it switches into Pan mode. If there is a shape under the mouse click area, then we must be in selection mode. I do this in MapSuite DesktopEdition 2.0 by switching modes in an overrided OnMouseDown event handler.


Will MapSuite 3.0 interaction be much the same as MapSuite 2.0? I haven't seen (map1.Mode etc) this anywhere in the API yet.


 



#2

I see that click and query is also scheduled for a later release… I can only assume that will address map modes / interaction etc. Am I correct?

#3

Brendan, 
  
   Modes also have an interesting history around here.  In our 2.0 product we have a number of modes from clicking to find features to panning etc.  The problem we found was that the more modes we added the less people liked them.  I mean that as we added modes that did one function we found that people wanted hybrids of different modes.  There seemed to be a limitless number of combinations based on their requirements.  After going through this I no longer wonder why Microsoft left it at things like Click, DoubleClick, MouseUp and MouseDown.  
  
   To give you an example of modes gone wrong in 2.0 we had a SelectFeatures mode or something like it.  We wanted to automate the process of a user clicking and then we do the spatial query and return the results of what they clicked over.  Well of course we had no idea of what layers you wanted to query on and if we queried all the layers that might not be very efficient.  To accomplish this we added something like a Selectable Boolean property to each layer and if that was true then we queried it.  The problem became that now we have an extra property on the layer that was only for some one-off feature that didn’t even apply for version other than the desktop.  It also meant the user had to find this property.  It also caused us to have to raise an event when it was done.  The other problem was that users had no way to change the behavior, you got our implementation that that was it.  The end result was a bad API and mass confusion.  What we want to do instead is have best practices and show people how to do it themselves. 
  
   Having said all of that our new approach is to really create some new events of our own and show people how to control their own destiny with modes.  For example we are adding an IsPanning property so you can check in a mouse move event if the user is panning or not.  We will also have a MapClick event that ensures you get the event only if the user clicks the map and they are not panning.  Of course you have all of the regular control events as well.  Our purpose is to show you how to use these events to create your own modes.  You might have a button saying “Feature Info” and when the user clicks that you go into feature click more.  You then wire up the MapClick event and check if your internal variable for that mode is set.  If it is then inside the event you do the spatial query to find what the user clicked on.  In this way you have the ultimate in control. 
  
   The challenge for us is to write samples and white papers to show you how to do these for many common scenarios.  Also we need to provide properties and events to allow you to do this in a straight forward and easy way.  We need to have easy to use methods to quickly do a spatial query given screen coordinates.  Better yet to provide world coordinated on the MapClick event to make things easy on you.  We want to really focus on making the powerful APIs easy and providing you with the correct event arguments so you don’t have to write a lot of conversion code. 
  
   I hope this makes sense and in the coming releases we will have more samples to show this.  Of course we are always open to suggestions and the best way for you to help us is to provide scenarios and we can give you an idea of how we would do them. 
  
   In the case you mentioned what we would suggest is to use the MapClick event which I think should be there.  You will only get that event if the user isn’t panning.  If you want to select the shape to move it then this is a bit more complex and will be handled by our shape editing stuff coming up in a near release.  With the shape editing the shapes will be on their own top layer and we will have lots of built in logic to know when you want to drag a vertex or if you want to move the shape we will have a little handle on it to make it easy to move.  These are the places we want to focus on some more hard coded modes and logic because there are only a limited number of correct ways to deal with them. 
  
   So after all of that please send us your scenarios and we will make sure to have samples to demonstrate them and try to make the code you write simple. 
  
 David

#4

“We will also have a MapClick event that ensures you get the event only if the user clicks the map and they are not panning.” You don’t know how that helps us. In MapSuite 2.0, we were overriding the MouseDown / MouseUp / MouseMove events and switching between panning and selection depending on whether the use had clicked on an object of ours, or moved a certain number of pixels etc.  
  
 What we’re looking for is “Google Earth” like click moving so that you can drag the map if you haven’t clicked on a dynamic shape… and “select” dynamic shapes if we do click on them.  
  
 We got this working the way we wanted in 2.0… but when you look at the code, no matter how cleanly you write it… it just looks like it wasn’t meant to do that.  
  
 I think this new way could really solve a lot of issues like you say. It’s good to hear. And thanks again for the insight.

#5

Brendan, 
  
 I’m sure 3.0 will be much better especially you want to custom and extend the functions, as we did a lot work on making our stuff scalable.   
  
 PS: we will have a new release tomorrow (Dec.12th), which doesn’t have the great features (editing/ Click & Query) added but has some bugs fixed. 
  
 Ben. 


#6

"PS: we will have a new release tomorrow (Dec.12th)" 
  
 Tomorrow… the 12th? :P

#7

Should be "Dec 2nd".  :P