ENC fails to load with error message "Invalid argument" and additional message "ENC resource path does not exist."

KennSebesta

Using the CPP version of the AddExchangeSet example, I try to load an ENC which fails at the point of loading the ENCLayer (code snippet below). When I print the `additionalMessage` error, I get "ENC resource path does not exist."

 

 

EncLayer* encLayer = new EncLayer(new EncCell(encDataset, this), this);
connect(encLayer, &EncLayer::doneLoading, this, [encLayer, this](Error e)
{
  if (!e.isEmpty())
  {
    qDebug() << e.message() << ": " << e.additionalMessage();
    return;
  }

  m_mapView->setViewpointGeometry(encLayer->fullExtent());
});

 

 

This same ENC works with the sample given by @LucasDanzinger in https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/trouble-getting-my-widget-to-display-an-enc/m-p/619973 , so it's a known good source.

What is different between these two examples, and what does "ENC resource path does not exist." refer to?

KennSebesta

Answered my own question. The following hardcoded line in the github example points toward an incorrect directory:

 

EncEnvironmentSettings::setResourcePath(defaultDataPath() + "/ArcGIS/Runtime/Data/ENC/hydrography");

 

Presumably, this was once correct in a prior version of the SDK, but as of v100.11 the hydography folder hs moved.

Simply removing the offending line allows the ENC to load correctly. Likewise so does pointing the path in the right direction.

I'm not completely sure what that line is even supposed to do, as it is not commented and when it is correctly pointed to the hydography folder installed with the SDK it doesn't seem to have any immediate impact.

Suggestions:

*) Within the example code, check for the presence of the folder, and return an error.

*) Improve the the example code with a comment which explains what this line does.

*) Most importantly, in the SDK code, print the name of the resource which isn't found. Since the SDK code knows precisely what it was unable to find, it should communicate that to us instead of dropping the file and/or path information. A fundamentally good pattern is that error messages should contain the maximum of information possible and they should not drop time-saving, salient information.