ThinkGeo.com    |     Documentation    |     Premium Support

Object reference not set after map closes

#1

I have an issue on my map where occasionally a user will ask the map to display a layer with a lot of features that would appear in the visible area, but before the map refreshes, the user will close the form that the map is displayed on. At some point a few seconds later I'll get an error about object reference not set. I'm disposing of the map when the form closes. Is there anything else I need to do? I'm running with multi-threaded turned on and I'm guessing that when the call that's getting the data returns, it finds that the map is not there. That's a guess obviously.


Here is the exception detail:


"   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.xfbd15a0e9d15f4e2(Graphics x783a718028818269, 

RectangleShape xb35a33b423b17f65)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.x7d52d0ad1d6779cd(Boolean x991dc8ddc7528b44, RectangleShape x178b193eec228e6e)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.xef6cc4fa8fda72d7(RectangleShape xb35a33b423b17f65, Overlay x99251f66cdabc2ad, Int32 xa209325f5c895f7e, Int32 x7454a0d1965919b1, GeographyUnit xbb704b4400ce6f76)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.xef6cc4fa8fda72d7(Object x9c95f4613bdc3113)\r\n   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)\r\n   at System.Threading.ExecutionContext.runTryCode(Object userData)\r\n   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)\r\n   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)\r\n   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)"


Anything suggestions/hints/ideas? Thanks!


Kimberly



#2

Kimberly,


I have tried to recreate your problem but can not make it. I built a sample that try to follow your way turn on the multi threaded mode, call map.Refresh() before Close() the form. I try to use large shape file that can make the drawing time longer.


Please modify the sample code which I provide and let it can recreate your problem.


Thanks


James



1716-TestForKimberly.zip (6.32 KB)

#3

James, the zip file doesn't have anything in it. Can you try again? :(


Thanks for the quick response though! :)


Kimberly



#4

Oops. I'm confused but now when I download the file, it has stuff in it. It gave an error about it being corrupted this time, but then it extracted. James, I'll take a look now and see if I can make your app have the same issue.


Thanks!



#5

James, I took your sample and made it crash on my machine. I'll attach the code that breaks. You'll need to fill in your view name, your connection string and your google api key. There are todo items for each of them.


The view that I'm referencing in sql server has 21557 records in it. No where near that many show in the extent that I'm using though.


The error specifically this time is: "Object reference not set to an instance of an object."


Stack Trace:


"   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.xfbd15a0e9d15f4e2(Graphics x783a718028818269, RectangleShape xb35a33b423b17f65)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.x7d52d0ad1d6779cd(Boolean x991dc8ddc7528b44, RectangleShape x178b193eec228e6e)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.x4821e882b9a40409(RectangleShape x178b193eec228e6e)\r\n   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.x5021a7a45adbb9ee(Object x3faa3e674cef60b0)\r\n   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)\r\n   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)\r\n   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)"


Thanks for taking a look at this James! :)



1727-TestFromKimberly.zip (18.2 KB)

#6

Kimberly, 
  
 Thanks for your post. 
  
 I can easily recreate your problem by the sample you attached. 
  
 This is particular case that you add map control to a MDI form with multi thread. If you use normal form, when you close the form, the main thread will be stopped, and the worker threads also will be stop because we set them to the background thread. But you use MDI forms, so if you close the child form, the main thread is still running, so the worker threads are still running too, at this time you call map.Dispose will set all member variable to null will cause the exception thrown. 
  
 So if you don’t call map.Dispose at the mapForm closing, it works properly. The resources will be released at frmParent closing, because you call mapForm.Dispose, it will call the map.Dispose because map is a sub control of mapForm. 
  
 Thanks 
  
 James 


#7

James, I'm afraid that this doesn't solve the problem. I had a note in the code where I was adding the form closing event handler that said that if you comment out the next line, that the problem still occurs.


Even without the call to the form close (and therefore, without specifically disposing of the map control), this still happens. As a matter of fact, I actually added the line to dispose of the map control to try to fix this problem specifically.


Any other ideas?


kimberly



#8

Kimberly,


I double check this issue, I run the updated sample from you with the version 3.1.299 MapSuite DLLs, it will throw the exception if I view the map and then click the button to close the sub form. But if you comment out map.Dispose, it won't throw exception.


void mapForm_FormClosing(object sender, FormClosingEventArgs e)
{
//mapMap.Dispose();
mapMap = null;
}


Thanks


James


 


 


 


 




#9

I have to admit that I'm really frustrated by your response. On my machine, using the exact code I sent you, but with the .dispose method commented out, this is still a problem as I said above. It DOES STILL throw the exception with that line commented out. Can one of the developers who has access to the code on this please take a look and see if they can find the issue that causes this?


And further more, I don't think it's bad coding practice to call the .dispose method on the control. I think the software shouldn't crash if a person calls the .dispose method on your control.


Kimberly



#10

Kimberly, 



I have added this topic to our Issue Tracker, we will discuss how to solve this problem. 



When we fix this problem I will let you know. 



Thanks 



James



#11

Kimberly, 
  
   I wanted to let you know we are going to take a look at it soon.  I am pretty sure it is being casued by us rendering the map on another thread and when you close things the thread is kind of left hanging, no fault of yours, and we need to add some logic to check to make sure the state is clean when we finish up. 
  
 David

#12

Kimberly, 
  
   I have also talked with James about the way he was answering some of the posts.  We want the forums to be a friendly place and we can’t have yelling or bad blood between people.  We are doing what we can to resolve your issues and I am looking into how we can make the process better on our end. 
  
 David

#13

 


Kimberly,
 
I recreated the problem with the help of your updated sample, and tried a lot of methods to solve it but seem it is too difficult to make it right immediately.  As a result, I added it to our Issue Tracking system and we will work on it later, hopeful we can fix it in next public release. “Comment out the Dispose” is just an expedient for my sample but not the solution for every case. Sorry for not making it clear at the very beginning and sorry for the misunderstanding. We will keep working on this issue and try to give you a good solution asap.
 
Thanks,
 
James

#14

Kimberly, 
  
   We are going to keep working on this.  James is just the first line to take a look at it.  I will peruse this with the development team and make sure it gets fixed.  You won’t have to wait for the next public release as this is a bug we will make the changes to our daily production build which has just fixes so it is very stable and is basily the last release code just with bug fixes. 
  
   The support team is still not that familiar with the new build system.  I will talk with them and make sure this gets straightened out.  Thank you for your patience on this. 
  
 David

#15

Kimberly,


We have reconsidered this problem more carefully and solved it, if you want; please pull down the builds (since build after 2/26/2010) in a day or two from now, I think it would be thereJ.
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale