Open jdduh opened 8 years ago
If it always happens, can you post the aoi? I will run it through the debugger.
Yes. the error handling is general when the form is opened. Without this error handling, ArcMap would crash when the form is opened.
I don't see that ILayer2 is used when the form loads, but it is used elsewhere in this manner: For i As Integer = 0 To pMap.LayerCount - 1 Dim nextLayer As ILayer2 = pMap.Layer(i) If TypeOf nextLayer Is IFeatureLayer Then Dim fLayer As IFeatureLayer = CType(nextLayer, IFeatureLayer) BA_RemoveAnnotation(fLayer) End If Next
So, there is probably a layer in the viewer that it doesn't like for some reason. A place to start. .
I find a bug related to the tool, but before I describe it I want to make it clear that NWCC folks can use Excel/eWSF to view and edit the parameters after exporting the file/importing it to eWSF.
This might be related the problem that David encountered. For the Gallatin_R_nr_Gateway AOI that I created, there are 33 HRUs. However, the parameter viewer shows that HRUs 34 to 40 have no-data values (-99) on all the BAGIS-P calculated parameters. Someone the viewer thinks that there are 40 HRUs.
The AOI (Gallatin_R_nr_Gateway_10162016.zip) is posted on the ftp server. Its file size is 127MB. ftp://basins.geog.pdx.edu/BAGIS/BAGIS_aois/
I did get the AOIs that David had problems to open with the Parameter Viewer. However, I have no problem to view their parameters with the Parameter Viewer. I noticed that David opened mxd files to begin his ArcMap sessions. I wonder if that caused the problem.
Can you get the .mxd from David?
The issue with the extra HRUs is related to the grid_zones_v file. This file is a copy of grid_v and created by BAGIS-P for use within the add-in. It is only created if it doesn't already exist. I think David ran BAGIS-P against a set of HRUs and then went back and cleaned up the tiny HRUs with BAGIS-H. Because grid_zones_v already existed in BAGIS-P, it wasn't generated with the smaller set of HRUs.
I updated the code to check and see if an existing grid_zones_v has the same number of hrus as grid_v. If it does, we re-use it. Otherwise we drop and recreate it. I thought about always recreating it but I think that will be slower and we store some items, like timberline elevations, in this layer so I don't want to delete it if we don't have to.
I don't think this caused the original problem with the viewer.
Here is the error message. I have yet to figure out a way to get around this, but it's not a critical step that prevents the subsequent tasks. I will provide additional information when I get a better sense of causes. It seems the error handling routine of the Parameter Viewer needs some improvements.