ThinkGeo.com    |     Documentation    |     Premium Support

Is WinformsMap.RestrictedExtent supposed to have an effect in version 5.0?

#1

What, if any, effect is WinformsMap.RestrictedExtent supposed to have in version 5.0?  I've tried using it, but it seems to apply absolutely no restrictions on the panning or zooming behaviour of the map.


Thanks,


Nicole



#2

 Nicole,


Thanks for your post.


I just did a quick test using ths new property and what it does is prevents the user from Panning outside of the restricted extent boundary.  However I can see how this may be confusing because the user can still Zoom out past the restrictedExtent and still see an area of the map that you may not want them to.


To make the map where the user can't Pan or Zoom outside of the RestrictedExtent I had to set the MaximumScale property as well.  To test it out take a look at the code below, you can just past it into the DispalyASimpleMap sample and overwrite the existing code in the DisplayMap_Load routine.


 




            winformsMap1.MapUnit = GeographyUnit.DecimalDegree;
            winformsMap1.BackgroundOverlay.BackgroundBrush = new GeoSolidBrush(GeoColor.GeographicColors.ShallowOcean);

            WorldMapKitWmsDesktopOverlay worldMapKitDesktopOverlay = new WorldMapKitWmsDesktopOverlay();
            winformsMap1.Overlays.Add(worldMapKitDesktopOverlay);

            winformsMap1.CurrentExtent = new RectangleShape(-139.2, 92.4, 120.9, -93.2);
            winformsMap1.RestrictedExtent = new RectangleShape(-139.2, 92.4, 120.9, -93.2);
            winformsMap1.MaximumScale = winformsMap1.CurrentScale;
            winformsMap1.Refresh();


#3

It looks like my original problem using that was probably due to some DLL caching problems in Visual Studio. However, now that I do have it working, I am seeing frequent stack overflows when zooming and panning in a restricted map. Here's the MapSuite part of the stack trace when these occur:




(... cycle continues...) 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentScale.get() + 0x40 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentExtent.set(ThinkGeo.MapSuite.Core.RectangleShape value) + 0x978 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.TRY=() + 0x2ca bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentScale.get() + 0x40 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentExtent.set(ThinkGeo.MapSuite.Core.RectangleShape value) + 0x978 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.TRY=() + 0x2ca bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentScale.get() + 0x40 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentExtent.set(ThinkGeo.MapSuite.Core.RectangleShape value) + 0x978 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.TRY=() + 0x2ca bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentScale.get() + 0x40 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.CurrentExtent.set(ThinkGeo.MapSuite.Core.RectangleShape value) + 0x978 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.FRY=(ThinkGeo.MapSuite.DesktopEdition.InteractionArguments FhY=) + 0x181 bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.BxY=(object CBY=, 8BM=.2Rc= CRY=) + 0x98 bytes 

DesktopEdition.dll!8BM=.hRU=.OnMouseEvent(8BM=.2Rc= e) + 0x3f bytes 

DesktopEdition.dll!8BM=.hRU=.nxU=(double oBU=, double oRU=, double ohU=, double oxU=) + 0x2da bytes 

DesktopEdition.dll!ThinkGeo.MapSuite.DesktopEdition.WinformsMap.DxY=(object EBY=, System.Windows.Forms.MouseEventArgs ERY=) + 0x2a8 bytes 

System.Windows.Forms.dll!System.Windows.Forms.Control.OnMouseMove(System.Windows.Forms.MouseEventArgs e) + 0x77 bytes



#4

Nicole, 



I used code to test what Clint provided, but I cannot recreate your problem properly, can you share your sample code to us so that we can recreate it exactly? Also I would like to ask you what's your development envrionment?  VS2010 or VS2008?



Thanks, 



Scott,



#5

I am using VS 2010, .NET 4.0, and MapSuite 5.0.0.0.


It looks like the stack overflow might be the result of window dimensions that cause the restrictions to "bounce" near a zoom level boundary when using zoom level snapping.  For example, I see a stack overflow (at the Refresh call) with the same cycle described in my last message if I alter the sample DisplayShapeMap.DisplayMap_Load method as follows:


this.Size = new Size(300, 300);

winformsMap1.MapUnit = GeographyUnit.DecimalDegree;
winformsMap1.BackgroundOverlay.BackgroundBrush = new GeoSolidBrush(GeoColor.GeographicColors.ShallowOcean);

WorldMapKitWmsDesktopOverlay worldMapKitDesktopOverlay = new WorldMapKitWmsDesktopOverlay();
winformsMap1.Overlays.Add(worldMapKitDesktopOverlay);

winformsMap1.CurrentExtent = new RectangleShape(-139.2, 92.4, 120.9, -93.2);
winformsMap1.RestrictedExtent = winformsMap1.CurrentExtent;

winformsMap1.MaximumScale = winformsMap1.CurrentScale;

winformsMap1.Refresh();


However, if I set the map's ZoomLevelSnapping property value to ZoomLevelSnappingMode.None, there is no stack overflow.


Nicole


 



#6

Nicole, 
  
 Thanks for your post and questions, I appreciate your sharing.  
  
 I think the reason to cause the stack overflow is probably in the statement to set the MaximumScale to the CurrentScale along with setting the ZoomLevelSnappingMode to Snapping Mode. 
  
 Any more questions please feel free to let me know. 
  
 Thanks. 
  
 Yale 


#7

Yale, 
  
 Yes, that’s rather obvious.  However, that particular bit comes out of Clint’s sample from 2011-05-19 14:04.  If it is part of the recommended approach for applying an extent restriction across both panning and zooming operations, it ought to work when zoom level snapping (the default and recommended behaviour) is in effect.  If it is not the recommended approach, then please suggest something else that does work as expected. 
  
 Thanks, 
 Nicole

#8

Nicole,


Thanks for your post and response.
 
I did found a sample to show how to use restrict extent for zoom out and panning, please take a look if you are interested.
wiki.thinkgeo.com/wiki/Map_Suite_Desktop_Edition_All_Samples#Restricting_Extent
 
Any more questions please feel free to let me know.
 
Thanks.
 
Yale

#9

Yale, 
  
 The sample to which you refer uses handling of the CurrentExtentChanging event to restrict the extent.  The new RestrictedExtent property available in 5.0 should, in theory, make this older approach unnecessary.  I would still very much like to know if there is an effective means of using RestrictedExtent in version 5.0. 
  
 Thanks, 
 Nicole

#10

 Nicole,


We have logged this issue with the product development team and they are currently looking at is as we feel it's a bug and not working properly.  We will keep you posted.


Thanks!


 



#11

Clint, 
  
 Thanks for pursuing the potential bug.  I hope that the dev team can find a way to fix it since the CurrentExtentChanging approach that we’ve been using isn’t as seamless as RestrictedExtent promises to be. 
  
 Thanks, 
 Nicole

#12

Nicole, 
  
 Thanks for your post and reporting. 
  
 Our development team will start to focus on this issue as soon as possible, hope we can get it resolved in the near future. We will keep an eye on this thread and get you updated once we found a solution for it. 
  
 Thanks. 
  
 Yale 


#13

 Nicole,


The dev team has reported back to me and say they have fixed the bug, additionally they said they also found an improvement for panning performance when researching this bug.  To try it out just download the latest daily build from the customer portal at helpdesk.thinkgeo.com and let us know if you run into any problems.


Thanks for reporting the issue!


 



#14

Clint, 
  
 I’m still seeing the problem in the 5.0.16.0 daily build (using the code from my 2011-05-20 08:23 post).  Should it be fixed in that build? 
  
 Thanks, 
 Nicole

#15

Nicole, 
  
 Sorry for the inconvenience, I just reported it to our development team again and we will do some more tests, if there are any updates I will let you know, 
  
 Thanks, 
  
 Scott,

#16

Nicole, 



We have fixed the bug for you, please get the latest version 5.0.18.0 from the DailyBuild of development branch to try again, 



Any more questions please let me know, 



Thanks, 



Scott,



#17

(Sorry for the delay in responding.  I've been OOF for the past couple of weeks.)


I have tried using RestrictedExtent with build 5.0.29.0, and the stack overflow exceptions have indeed disappeared.  However, now that I'm able to use it without crashing, I've discovered a couple of additional problems.  Both occur when using the map.MaximumScale = map.CurrentScale approach to scale control that was recommended in Clint's 2011-05-19 14:04 post.


The first problem is a bit subtle.  After the map is first displayed with map.CurrentExtent = map.RestrictedExtent, attempting to zoom out (i.e.: exceed the specified maximum scaled) using the mouse scroll wheel pans the map.


The second problem is more obvious.  When the map in is PreserveExtent resize mode, resizing the map control doesn't result in reliable extent preservation since the MaximumScale has been set to correspond to the MaximumExtent scale at the original control size.


While it would probably be possible to work around the second problem by intercepting the map control's Layout event, this really shouldn't be the responsibility of the consuming developer.  I have a very hard time imagining that many users would want to use RestrictedExtent for panning without applying it to zooming as well, and I have to wonder why you haven't included scale restriction within the RestrictedExtent functionality.  Wouldn't the simplest implementation be to intercept any attempt to change the "core" current extent (before zoom level snapping), and set it to the intersection of the target extent and the restricted extent?  If there actually is demand for pan-only restriction, should this perhaps be an option instead of the default behaviour?



#18

Nicole, 
  
 Thanks for your questions！ 
  
 Can you arrange a simple sample to us so that we can recreate your problem properly, according to the two issues what you described above, I cannot reproduce it and I need your sample to check them exactly. Also if it is possible can you explain the second problem more clear and tell me how to recreate it based on your sample application? 
  
 Thanks, 
  
 Scott,

#19

I'm attaching a sample that shows both problems.  (I didn't use the WorldMapKitWmsWpfOverlay because I can't seem to access the server at the moment, not because the problem can't be demonstrated using its map content.*)


Before compiling the sample, add the strongly named assemblies from the 5.0.31.0 daily build to the Dependencies folder.


To demonstrate the first problem, simply run the executable, then attempt to zoom out using the mouse wheel (i.e.: spin it towards yourself) as soon as the map is first displayed.  In most cases, I see the map pan at this point.  If you're very (un)lucky, the random point generation might avoid the problem.  In that case, simply click the "Repopulate" button, then try zooming out via the mouse wheel again.


The maximum scale issue actually leads to several problems.  One of the simplest demonstrations is to simply shrink the form after opening (or after clicking either the "Scale to fit" or "Repopulate" buttons if you've already been mucking about on the open form).  Since the map is in PreserveExtent resize mode, we are hoping to see the current extent preserved as the form is shrunk.  However, the MaximumScale setting prevents this, and we end up seeing a piece of the pre-shrinking extent at a conserved scale.



*Based on exception details, I suspect that this may be due to an incorrect server address embedded in recent daily builds.



RestrictedExtentSample.zip (35.8 KB)

#20

 Nicole,


Thanks for your sample and further information about the issues!


For your first issue, I ran the sample application directly and zoom out by mouse wheel, but I don't see any problems on that, when I zoom out by mouse wheel, I just saw the points on the map had a small offsets. Did you mean that?


For your second issue, after I ran the sample and I shrink the form many times, I recreate the problem, some of the points were disappeared and the extent is changed. I reviewed your sample code and I modified it as below for the InitializeMapControl method:


 



private void InitializeMapControl()
{
            this.map.MapResizeMode = MapResizeMode.PreserveExtent;
this.map.MapUnit = GeographyUnit.Meter;
this.map.MinimumScale = 0;
this.map.AdornmentOverlay.ShowLogo = false;

            //this.map.ZoomLevelSet = MapUtility.PartitionZoomLevelSet(5, this.map.ZoomLevelSet);
            MapUtility.PartitionZoomLevelSet(5, this.map.ZoomLevelSet);

            this.AddMapBackgroundImage();
this.AddFeatureLayer();
}
  I commented the MapUtility.PartitionZoomLevelSet code and ran the sample again, during I shrink the form it seems works fine. So currently, I'm not sure it is a bug for desktop edition, can you review your sample code again to make sure your calculation logic is correct?  


Thanks,


Scott,