ThinkGeo.com    |     Documentation    |     Premium Support

Map Thread Monitoring

#1

There have been a number of times when during the course of fighting with the threading issue of recent fame, that I looked for but did not find the equivalent of an IsDrawing property.


Meaning, that I can check to see of the map thread used to render it on the screen is REALLY finished or not.


For example, having a WaitCursor displayed so that the user knows not to continue clicking away on buttons while the map loads.

Putting a cursor change anywhere is useless, because the main code finishes but when a Map1.Refresh is called, it initiates a thread that carries on it's merry way.


Now, I'm working to implement a transparent control (which works), but when the map refreshes, it vanishes completely and would require a refresh call of it's own, but the map has to be finished first.


Any ideas on how to monitor the map.refresh thread?



#2

Kirk, 
  
   I understand what you mean.  We are looking into this.  From what I have heard there will be a few new things added when the threading comes back.  The first is a processing spinner on the map like the Web Edition and also like Ajax style applications.  The second is a locking mechanism so that while the map is drawing you can try and lock it.  When it is drawing your process will wait until the drawing is done.  Third will be a way to check the lock without blocking.  In this way you can check, like what you mentioned IsDrawing and see if we are busy drawing.  While I don’t have anything more concrete then rumors these kinds of features will defiantly be in there to support the cases you bring up.   
  
   From what I hear the main threading discussion are on how concurrent we do we really need to be.  I mean do we need to be able to draw 3 maps at one time that share the same layers?   Do we need to just be able to draw on map while have the UI be responsive?  We are looking at allot of possible paths on this.  Each one has its own best locking strategies and drawbacks.  I will share more as I find out.  Any input you, or anyone one else, would have is invaluable. 
  
   As to your specific question I will have to ask the team.  If you are using the single threading mode then it doesn’t matter much because after the refresh no other code can run until it is done.  Is this what you are doing or are you mainly asking for once multi threading is turned back on and prime time? 
  
 One other note is that with future builds of the Desktop Edition we will be introducing lots more events to help out.  We have been getting lots of feedback on useful events especially around editing.  If you have requests let me know. 
  
 David

#3

Glad to hear that those features are being considered they all sound useful. 
  
 Right now, it’s not as much of a problem as am using the single-thread. 
 But even with that, the map does it’s own thing even after the code I’ve written is done. 
 I don’t use threads anywhere else in my application, so the map thread is the only one running. 
  
 But where I found some of the difficulty with the multithread version is when a user click on the map, it finds the feature, zooms into it (sets the currentextent to the feature’s bounding box) and then dynamically determines what detail files to add to the layer and then adds features (highlights/markers) based on the current extent. This requires a couple of refresh calls and when the first isn’t done yet, it would crash or the added features would not render. 
  
 Had I been able to wait for the first refresh to finish, the problem would have been solved.

#4

Kirk, 
  
   I will be sure to have the Desktop Team test case for this.  It is a very useful and probably typical way for people to use the map.  Thanks and any other feedback or comments are especially welcomed. 
  
 David