ThinkGeo.com    |     Documentation    |     Premium Support

What happens on ShapeFileFeatureLayer.Close()

I'm getting a very strange error in a project I'm trying to update from V2 to V3 of Desktop Edition.  We have our own custom DB spatial storage system using WKB and have used MapSuite to calculate BBox and Area of individual polygons, etc.  We also used an older version of NTS, which I upgrade to the most recent through out out code last week without any issues.  I've ported the code to V3 of MapSuite and it works fine until I close the ShapeFileFeatureLayer in our test application.  A windows exception is thrown, causing the process to be shutdown by windows.


I reference our dll in a stand alone application and no problems happen so there must be some strange interaction with other code in our test app, but I'm at a loss to understand what.  I've attached the only error I get when the problem happens (when debugging or not).  Attaching to the dying process yields a stack tract that is in native code and looks like in windows dlls.  This is running on Vista x64.


This error happens even if I just call Close() right after calling Open(), but only in our test app.  I was wondering if you might be able to give me some insight of what is happening in ShapeFileFeatureLayer.Close() to help me identify the conflict that is happening.


I'd send some sample code, but the system is rather large and requires a db setup to run against and I'm un-able to do a simple re-pro.




UPDATE:


I was just updating the code we use get the BBox and Area of an image layer.  To do this I just created a Proj4Projection to convert the world files UTM coords to lat/lon and when I closed the Proj4Projection object I received the same error.  I've put a code snipped below to help, it dies on the projection.Close() call. 



Here is a better pasting of the source code...helps if I read the stickys :-)



protected virtual void SetGeometryProperties(
            ITccRasterLayer layer)
        {
            var bbox = thinkGeoImageLayer.GetBoundingBox();

            //Set Acres
            layer.Acres = bbox.GetArea(GeographyUnit.Meter, AreaUnit.Acres);

            //Set the UTMZone
            if(UTMZone == int.MinValue)
                throw new NotSupportedException("A UTM zone must be set to create a TccRasterLayer.");

            //Create the ThinkGeo projection class to get from UTM to Lat/Lon
            var utmSystemID = ProjectionHelper.CreateUTMSystemReference(NorthernHemisphere, UTMZone);
            var projection = new Proj4Projection();
            projection.ExternalProjectionParametersString = Proj4Projection.GetEsriParametersString(ProjectionHelper.CreateGeoDeticWGS1984SystemReference());
            projection.InternalProjectionParametersString = Proj4Projection.GetEsriParametersString(utmSystemID);
            projection.Open();
            var unProjectedBBox = projection.ConvertToExternalProjection(bbox);

            //Set the bounding box
            layer.MaxX = unProjectedBBox.UpperRightPoint.X;
            layer.MaxY = unProjectedBBox.UpperRightPoint.Y;
            layer.MinX = unProjectedBBox.LowerLeftPoint.X;
            layer.MinY = unProjectedBBox.LowerLeftPoint.Y;

            //Close the projection
            projection.Close();
        }


Just tested nulling out the Projection property on the FeatureSource of the ShapeFileFeatureLayer before calling the Close() method and it doesn’t error, so it must be something with the projection

Brian, 
  
   Interesting.  When you call the close on the projection we go to free up the resource by using the Proj4’s free method.  I would image that that is causing the problem.  Why, om the other hand, I have no idea.  It makes sense though as when the Layer gets closed it will call the close on the projection object as you found out.  I will see if we can re-create this on our end.  I think we can get to the bottom of this. 
  
   If you could respond to this post it would help as it keeps it open in my work queue.  I can then assign it to someone later today to be looked at tomorrow. 
  
 David

Thanks David,


If I don't close the projection the app still dies on exit, I assume because the Projection object is being disposed.  This app does reference coms dlls also, I don't believe any are in use when I'm using the projection class, but I'm not positive.  Referencing our SpatialStorage dll in a simple test app does not cause the problem (no com references there), but we have to be able to have those com objects in our production apps (as much as I wish we didn't).  I can send you the sample that works if you'd like, but it couldn't get it to attach to this message.


Brian



Brian, 
  
   A sample would be helpful.  You can e-mail it to Support@ThinkGeo.com 
  
 Also if you could include your system 32 dlls for the projection stuf, it is in a sub directory of your system 32 or system 64 folderf.  I think it is like X64Projection or X64MapSuite dependencies.  Just so we can compare that, maybe you have a corrupt DLL. 
  
 David

Sample on the way, I haven’t found the dlls in System32…only the raster layer stuff…I’ll keep looking

Found them, has the x64 on the end instead of the front, e-mailed also

Brian, 
  
   I got the files, thanks.  I will have to call on Monday, we will see what we can find though before then. 
  
 David

Thanks David, 
  
 I’ve got it understood enough to work around the issue pretty easy, but would be nice to figure it out.  I’ll try to find a few minutes to make a simple re-pro app to send you.

Brian, 
  
   Sounds good.  Did you need me to call you about this today or can we work it out via e-mail? 
  
 David

Hi David, 
  
 I’ll try to get to that test app today and see if it happens in it.  I’ll let you know when its ready and then you can review and we can discuss further if needed.  It has to do with the proj4 being first used in a UI class first I think.  We have a UI framework that uses user controls and if the first projection is created in the user control it fails, if you make one in the program’s ‘main’ method and then in user controls it works fine.  Just want to make sure we get the problem communicated well. 
  
 I’ll post on this thread when the test app is ready and we can go from there. 
  
 Thanks 
 Brian

Brian, 
  
   Sounds good. 
  
 David