ThinkGeo.com    |     Documentation    |     Premium Support

CustomStyles and IsActive

#1

Can someone explain to me how the IsActive property of CustomStyles is supposed to work?  I've added two point styles to a ZoomLevel's CustomStyles and it displays both, as I would expect.  (A big green square with a smaller green circle inside or the other way around...)  I have two checkboxes, one for each of these styles, and when the checkbox changes I set the IsActive property of the corresponding to the value of the checkbox, in the hope of being able to turn the styles on and off via user interaction.  I then refresh the map, but both styles continue to display.  I even reapply the "ApplyUntilZoomLevel".  Is this what "IsActive" is supposed to do or am I reading things wrong?  If I'm wrong, how could I turn specific styles in the CustomStyles collection on or off via code?  I'm doing some testing for a scenario where map styles can change based on an application action.


Thanks,


Allen



#2

Hi Allen,


Thanks for your post!
 
I guess you didn’t add the write lock to the overlay when you change the custom style of the layer in it. You should write the code like this if you want to change any thing in the overlay.
 


winformsMap1.Overlays[0].Lock.EnterWriteLock(); 
try 
{
 ShapeFileFeatureLayer currentLayer = winformsMap1.FindFeatureLayer("WorldLayer") as ShapeFileFeatureLayer;
 currentLayer.ZoomLevelSet.ZoomLevel01.CustomStyles[0].IsActive = cbxStyles1.Checked; 
} 
finally 
{
 winformsMap1.Overlays[0].Lock.ExitWriteLock(); 
} 
winformsMap1.Refresh(); 


 
 
I also make a sample for you based on your description, and it works fine. You can get it from the attachment and have a try. I didn’t put the data file in it; you can get the “MajorCities” data from the HowDoISamples’ SampleData folder. 
 
Any more questions please let me know.
 
Thanks,
 
sun

964-Post6044Demo.zip (10.6 KB)

#3

Sun, 
  
 Thanks for the response.  I think I’ve been a little confused on when I need to use the EnterWriteLock and ExitWriteLock.  It appears that SOME things refresh without it, but I just haven’t figured out exactly what.  I believe that led me to think if I’m in single-thread mode (which my little test program was) I didn’t need to do the EnterWriteLock and ExitWriteLock, but as soon as I did that it worked just fine. 
  
 Thanks! 
 Allen

#4

Allen, in single threading, it is not necessary to use the locks, as you suspected.  However, in the abscence of that, there is an IsDirty property or something like that on the overlay.   You must set that.    It gets set for you when you do the ExitWriteLock.  The map.Refresh evaluates this property to see if the overlay needs to be drawn… no matter whether threading or not.

#5

Ted, Thank for your sharing! 
  
 Allen, I think what Ted said is absolutely right, while in single threaded mode, we still suggest using lock instead of setting the IsDirty property manually, because we are considering to  remove this property in later public release. 
  
 Let me know if you have any more questions. 
  
 Thanks. 
  
 Yale 


#6

If I may make a suggestion, should you consider two enhancements? 
  
 1)  Overload the Map.Refresh method with a Map.Refresh(boolean refreshAll)  so this could be set to true, and the refresh would treat every overlay as if "IsDirty" is set. 
  
 2) Overload the Map.Refresh method with a Map.Refresh(Overlay overlayToRefresh) method.   This would cause an explicit refresh of a single overlay. 
  
 For simple applications, this might be easier than teaching people about the lock approach to getting overlays to refresh.    The lock approach would always be the preferred method, though. 


#7

Ted, Thanks for you great suggestions, we appreciated it very much. 
  
 Now, we already on the way to change the lock system to make it easy to use and understand, and I have reported your ideas to my direct, hopefully we can get it. 
  
 Thanks again for your suggestions. 
  
 Yale 


#8

Ted and Yale… 
  
 Good exchange of ideas there.  Indeed, I think at some point in time I discovered setting IsDirty would do the trick without actually using EnterWriteLock, probably by accident!  I think Ted’s suggestions have some value, but if I have to explicitly code the Enter and ExitWriteLock I’m sure after NOT doing it a few times and wasting time wondering why my map didn’t refresh it will become automatic.  Knowing that IsDirty may be going away will probably convince me to use Enter and ExitWriteLock. 
  
 Allen

#9

Allen, 
  
 Thanks for your comments!  
  
 I agree to remove the IsDirty property from Lock and now we are on the way, Our main purpose for this change will be try to make it easy to use for the Lock system, hopefully it would be ready in the next release. 
  
 Thanks for your guys great ideas! 
  
 Thanks. 
  
 Yale