ArcGISLocalFeatureLayer Path set via app.config file or code-behind?

[KeithGemeinhart]

I'd like to have the Path property for an ArcGISLocalFeatureLayer be a value that is not hard-coded. Is it possible to set the value in code-behind or somehow use a value from the app.config file directly in xaml to set it?

I tried binding to an app.config values using the following technique:
http://dean-o.blogspot.com/2009/10/wpf-binding-appconfig-settings-in-xaml.html
http://www.codearsenal.net/2012/03/accessing-appconfig-properties-from.html#.UIGz6NeaZ1o

But I get the following error ...
A 'Binding' cannot be set on the 'Path' property of type 'ArcGISLocalFeatureLayer'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject.

[BKuiper]

This can not be done in XAML, you will have to do this in code behind. As you discovered, Path is not a Dependency property.

[KeithGemeinhart]

Any pointers on how to do that in code behind?

[MichaelBranscomb · Accepted solution]

Hi,

Please see the API reference on ArcGISLocalFeatureLayer for more information and code examples: http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client.Local~ESRI.ArcG....

Cheers

Mike

[KeithGemeinhart]

Wasn't sure if LocalFeatureService was the way to go or not. Thanks!

[MichaelBranscomb]

Hi,

Actually, the ArcGISLocalFeatureLayer will automatically create the LocalFeatureService in the background (if it is not already running) when you set the Path property and the layer is initialized (either by adding the layer to the map or by you calling Initialize). Alternatively you can work with the LocalFeatureClass directly - which would give you greater control over when the service lifecycle in relation to the lifecycle of your application and also over additional properties which may be available on the service but not on the layer.

Cheers

Mike

[KeithGemeinhart]

Can you point to any resources that describe the service lifecycle? I've implemented it as shown below, but my first stab at it yielded an exception ("Path property cannot be changed when the service is running."). Now that I've added the stop & start calls before setting the path, it works fine, but that seems to be really inefficient - especially since the service has apparently started once already. There was a noticeable delay on the start call.

Is there any way to attach and set the path earlier in the process?

<esri:ArcGISLocalFeatureLayer ID="DtedFootprint" LayerName="DtedFootprint" Path="C:\\xxxxx\\yyyyy\\maps\\DtedFootprint.mpk" />

var dted = _view.MapControl.Layers["DtedFootprint"] as GraphicsLayer;
dted.Initialized += new EventHandler<EventArgs>(dted_Initialized);

and

void dted_Initialized(object sender, EventArgs e)
{
     var layer = sender as ArcGISLocalFeatureLayer;

     layer.Service.Stop();
     layer.Service.Path = System.IO.Path.Combine(sPackageLocation, sDtedPackage);
     layer.Service.Start();
}

[MichaelBranscomb]

Hi,

From your code example what will likely happen is that the XAML layer initialization will begin first and start the LocalFeatureService creation (which in turn will start the LocalServer if it is not already started). Once the localserver/service are ready and the layer is initialized your code then appears to stop that service, set the path and starts the service again. If I'm right, this means you're incurring two service startup delays. These local services typically start quickly but it's recommended to try to start them as early as possible in the lifetime of the app, and asynchronously so that when the user starts interacting with the map the layers are ready to go. It is not advised to change the path of local feature service (you'll likely want to set different properties) and definitely not with the same feature layer in the map (many properties could be different), unless you were going to reinitialize the layer.

If you're trying to achieve the flexibility of managing the local services in code then I think it would be better to handle the layer management in code too. There is an exmaple of this in the API Reference: http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client.Local~ESRI.ArcG....

But you have highlighted to me that we should review the documentation on local layer/service management and where possible be more explicit about the behaviour and recommended patterns.

Thanks

Mike