ExportCAD tool - does size matter?

250
8
07-19-2011 04:06 AM
Highlighted
New Contributor
Hi all

I'm trying to export some data to .dwg, and facing a difficulty. For small files, like layers with about 10KB, the ExportCAD tool works fine. But if I try to export some .lyr file about 50KB or more, the IGeoProcessorResult don't even create an output. Here is the code I'm refering to (in C#):

          ExportCAD pExportCAD = new ExportCAD();
          Geoprocessor pGP = new Geoprocessor();
          object obj = Type.Missing;
          IGeoProcessorResult pResults;
          string strOutType = "DWG_R2000";
          string strOutFile = @"C:\Temp\Arquivo Exportado GEO.dwg";

              pGP.OverwriteOutput = true;
              pExportCAD.in_features = @"C:\Arquivos de Programas\ArcGIS\ArcGlobeData\World Image.lyr";
              pExportCAD.Output_File = strOutFile;
              pExportCAD.Output_Type = strOutType;
              pExportCAD.Ignore_FileNames = "IGNORE_FILENAMES_IN_TABLES";
              pExportCAD.Append_To_Existing = "OVERWRITE_EXISTING_FILES";
              //pExportCAD.Seed_File = "seed2d.dgn"; 

            
              if (pGP.Exists(pExportCAD.in_features.ToString(), ref obj))
              {
                  pResults = (IGeoProcessorResult)pGP.Execute(pExportCAD, null);
                  MessageBox.Show("Processado");
              }

          }


I'm askinig for help, because I did not find anything about this issue. After that, I would like to export select data, not the entire leyer. I'm still researching about this, but if someone has already some hints, I would appreciate too.

Thanks in advance

Rodrigo Salvador
COPEL
Geoprocessing Developer
Curitiba, PR, Brazil
+55 (41) 84038660
Reply
0 Kudos
8 Replies
Highlighted
Regular Contributor III
I don't see any error handling that will show you the error message if an exception is thrown.  Are you checking the geoprocessing results object for any messages?  What happens when you run this same tool from ArcToolbox on the same data?
Reply
0 Kudos
Highlighted
New Contributor
Thanks for the answer, Neil

The content of pResult was null while debugging, and the catch clause was not being called. I did not tried to use the tool window in ArcMap, and when I did it I realize the real issue: The type of the .lyr files. They were not features classes, nor feature layers, nor shapefiles, the only types accepted by ExportCad(). Whitout your question, I would not realize that.

So, now my work is to figure out why the .lyr files are not saved as feature classes, in order to be able to export them. I still can't export neither using the tool nor the code, except for the small files I mentioned, but these ones are defined as feature classes, unlike that ones.

Thanks so much.

Rodrigo Salvador
COPEL
Geoprocessing Developer
Curitiba, PR, Brazil
+55 (41) 84038660
Reply
0 Kudos
Highlighted
Regular Contributor III
A layer file doesn't contain any data.  It's a serialized layer object.  Instead of using a layer file, try using the data that the layer file points to.
Reply
0 Kudos
Highlighted
New Contributor
Thanks again, Neil. It was very helpful. I'm redirecting the call to de geodatabase, and not to the .lyr files anymore.

Unfortunately, I'm not sucessful yet. The method IFeatureDataset.FeatureClass.PropertySet is throwing a COMException (HRESULT E_FAIL code:2147467259, which I found to be a generic error) when calling the feature class in the referenced geodatabase. I'm sure the connection is fine, because the map and its funcionalities are ok on the screen. I guess it's another thread, beyond the proposite of this topic, but I would appreciate some links that help me on the research to solve this thing.

Rodrigo Salvador
COPEL
Geoprocessing Developer
Curitiba, PR, Brazil
+55 (41) 84038660
Reply
0 Kudos
Highlighted
Regular Contributor III
pExportCAD.in_features = @"C:\Arquivos de Programas\ArcGIS\ArcGlobeData\World Image.lyr";

All you should need to do is change this line to the path to the feature class.  If you are unsure what this path should be then you can browse to the feature class in ArcCatalog and copy the text you see in the Location box at the top.  You should also be able to set in_features to the actual feature class object, which you can get from the map layer or by connecting to the workspace and opening the feature class.
Reply
0 Kudos
Highlighted
Regular Contributor II
The Geoprocessor GetMessage or GetMessages will return the messages, including any failure, error codes and hints for the failure reasons.  When calling Geoprocessor, after it executes, success or failure, I like to output the messages to a log or a trace so I can diagnose the problems.  It might help here.  If you can post the messages it might be easier to help.

Another thing I like to do when debugging Geoprocessing calls in ArcObjects, is to get some clean runs using ArcCatalog or ArcMap first.  It eliminates a bunch of problems which are easier to debug in the interface.
Reply
0 Kudos
Highlighted
New Contributor
Neil, I did as you told. The path to a feature class in my project is like this:
"C:\Documents and Settings\Salvador\Dados de aplicativos\ESRI\ArcCatalog\admteg_geosde1dsv.sde\TEG.FIBRA_OPTICA"
So, as you see, it goes into a database connection (in bold) to find the feature class. And it takes a long time process. We have, inside the code, a class to handle this connection, in order to don't need to do it every time we want to export data. But it's inside this class that the COMException appears. Do you have a suggestion to make this connection smarter? Setting the path is actually the best way to avoid the error?

Alexander, thanks for the hint. I asked for the messages, but there is no returning. I mean, "GP.GetMessage(0);" and "object obj = Type.Missing; GP.GetMessages(ref obj);" returns empty when the error happens. I guess it happens because some other class throws the Exception, not the GeoProcessor. I was able to find the error I mentioned, in IFeature.FeatureDataset.PropertySet, only in Visual Studio debug. But I'll keep your suggestion in mind for other uses of GeoProcessor Class.

Once again, thank you both for the help.
Reply
0 Kudos
Highlighted
New Contributor
Hi again

I'm back just to get my last question off. The "long time process" I said was not caused by the database connection. It means the solution proposed here is perfectly right, the data are exported ok, even the bigger ones (over then 100MB).

This thread is resolved, thank you so much. Now I'll begin to look out for exporting selected features, and I'll come back here in case of troubles.
Reply
0 Kudos