Latest Contributions by MichaelBranscomb

Hi, Creating Map and Tile packages is the recommended approach. However, we're well aware that many folk still like to let users add Shapefiles, Geodatabase feature classes and rasters directly to a map and let them set the symbology. We are planning to improve our support for more adhoc data workflows in a future release but for now it's still relatively easy to add Shapefiles and Rasters. Geodatabase feature classes are fine too if you know the feature class names beforehand. Take a look at this sample which demonstrates the process: http://www.arcgis.com/home/item.html?id=953a530ada30477d95cc69e788268bc9. The API explanation can be found here: http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer.html. Cheers Mike ... View more

Hi, UNC paths should work - i just retested a local MPK with layers referencing data via a UNC path and also the MPK itself via a UNC path and both worked fine. If you're still getting the same error then you could try deleting the contents of Documents\ArcGIS\Packages - although it should unpack the MPK again if you've recreated it. Cheers Mike ... View more

Hi, When creating the package did you check the box for support ArcGIS Runtime? If you don't see this on the map packaging dialog then you'll need to enable the ArcGIS Runtime tools in the options > sharing dialog - more info here: http://resources.arcgis.com/en/help/runtime-wpf/concepts/index.html#/How_to_create_a_map_package/01700000005t000000/. To create a standalone utility you can use python and the Package Map GP tool but it will still need a desktop license. Cheers Mike ... View more

Hi, There's a help article in the Desktop help which covers including Python libraries within your GP packages: http://resources.arcgis.com/en/help/main/10.1/index.html#/Packaging_Python_scripts/0057000000mn000000/. Cheers Mike ... View more

Hi, We have already developed a preview app and made it available in the Windows Store in order to demonstrate ArcGIS functionality in the Windows 8 environment: http://apps.microsoft.com/webpdp/en-us/app/arcgis/db733971-3cc8-4db9-ae5a-865f2853a960. At the next release we are planning to support the existing ArcGIS Runtime SDK for WPF on Windows 8 and Visual Studio 2012 which will allow you develop applications for the Windows 8 Desktop mode (as well as cotinuing to support your customers on XP, Windows 7, etc). That SDK will continue to target .NET 4.0 but you can of course use .NET 4.5 functionality as well. In terms of building apps in the Windows 8 modern UI style, and which support WinRT we are working on a new sdk for Windows 8 which will be available next year. Cheers Mike ... View more

Hi, I have to admit it took me a little while and a fair amount of Googling to figure this out - but the solution seems to be to set the SynchronizationContext of the main thread to a new DispatcherSynchronizationContext e.g. var syncCtx = new DispatcherSynchronizationContext(); SynchronizationContext.SetSynchronizationContext(syncCtx); The issue is that the Initialized event is firing on a different thread from the one on which the FeatureLayer is created, hence the exception you're seeing about the calling thread. As far as I know, this shouldn't happen. Working with your code in a console application I added additional code in each event (Initialized and UpdateCompleted) to get the Dispatcher of the FeatureLayer then call CheckAccess on that Dispatcher which confirms whether an Invoke is required to post back onto the calling thread. I also added code to write out the current thread id, just so I could easily check what was going on. This confirmed that the Initialized event was always firing on a different thread but I do not know why and even when I did call Dispatcher.Invoke (or .BeginInvoke) to post back on to the original thread it still failed with the same exception. A colleague suggested I should check the SynchronizationContext of the main thread and of the thread on which the event was firing. However, the SynchronizationContext of the main thread was always null and unfortunately I still do not know the reason for this - but it seems to be the reason why the event was firing on a different thread. Fortunately I found a blog post which, although addressing a different use case, showed me how to make sure there is a SynchronizationContext (http://blogs.msdn.com/b/pfxteam/archive/2012/01/21/10259307.aspx) - see code snippet above and full code below. Once I had added this code it worked perfectly. The code may not even need all the Dispatcher checks/invokes once the Sync Context is now set but I think it's good practice in this scenario. Here's the full code: using System; using System.Threading; using System.Windows.Threading; using ESRI.ArcGIS.Client; namespace UpdateGraphicsConsole {     class Program     {         static string _url = "http://sampleserver6.arcgisonline.com/arcgis/rest/services/Wildfire/FeatureServer/0";         // Make sure the main thread is an STA thread         [STAThread]         static void Main(string[] args)         {             // For some reason the SynchronizationContext of the main thread is null.             // Create and set a new DispatcherSynchronizationContext.             var syncCtx = new DispatcherSynchronizationContext();             SynchronizationContext.SetSynchronizationContext(syncCtx);             // Get the current dispatcher to check thread access.             Dispatcher d = Dispatcher.CurrentDispatcher;                         // Create a FeatureLayer             FeatureLayer fl1 = new FeatureLayer             {                 Url = _url,                 ID = "23",                 Mode = FeatureLayer.QueryMode.Snapshot,                 AutoSave = false,             };             // Report which thread the FeatureLayer was created on             Console.WriteLine("FeatureLayer created on Thread " + d.Thread.ManagedThreadId.ToString());             // Register a handler for the Initialized event             fl1.Initialized += (sender, eventArgs) =>             {                 // Report which thread the event fired on (this was always a different thread until the DispatcherSynchronizationContext was set                 Console.WriteLine("Initialized event handled on Thread " + Dispatcher.CurrentDispatcher.Thread.ManagedThreadId.ToString());                 // Get the FeatureLayer                 FeatureLayer fl2 = sender as FeatureLayer;                 // Get the FeatureLayer dispatcher                 Dispatcher d1 = fl2.Dispatcher;                 // Report the thread we're invoking the Update call on (this was always the original thread)                 Console.WriteLine("Invoking Update on Thread " + d1.Thread.ManagedThreadId.ToString());                 // CheckAccess always returned false because this code was running on a different thread until the DispatcherSynchronizationContext was set                 if (fl2.Dispatcher.CheckAccess())                 {                     fl2.Update();                 }                 else                     d1.BeginInvoke(                         DispatcherPriority.Normal,                         new Action(delegate()                             {                                 fl2.Update();                             }));             };             // Register a handler for the UpdateCompleted event and call SaveEdits()             fl1.UpdateCompleted += (sender, e) =>             {                 // Get the FeatureLayer                 FeatureLayer fl3 = sender as FeatureLayer;                 // Get the FeatureLayer Dispatcher                 Dispatcher d2 = fl3.Dispatcher;                 // Update the graphic attribute (or perform any other edits)                 fl3.Graphics[0].Attributes["description"] = Guid.NewGuid().ToString();                 // Write out the new value                 Console.WriteLine(                     "Updated Graphic ObjectID "                     + fl3.Graphics[0].Attributes["objectid"]                     + " with Description: "                     + fl3.Graphics[0].Attributes["description"]);                                 // Call CheckAccess to confirm whether we need to post back to the original thread                 // Then call SaveEdits                 if (fl3.Dispatcher.CheckAccess())                 {                     fl3.SaveEdits();                 }                 else                     d2.BeginInvoke(                     DispatcherPriority.Normal,                     new Action(() => fl3.SaveEdits()));             };             // Register a handler for the EndSaveEdits event and write out the status             fl1.EndSaveEdits += (sender, e) =>             {                 Console.WriteLine(e.Success ? "Success" : "Fail");                 // Can check results online at query endpoint (by description value, objectid, etc)                 // http://sampleserver6.arcgisonline.com/arcgis/rest/services/Wildfire/FeatureServer/0/query             };             // Register a handler for the InitializationFailed event             fl1.InitializationFailed += (sender, e) =>             {                 // Report error                 FeatureLayer fl4 = sender as FeatureLayer;                 Console.WriteLine(fl4.InitializationFailure.Message);             };             // Register a handler for the UpdateFailed event             fl1.UpdateFailed += (sender, e) =>             {                 // Report failure to update layer                 Console.WriteLine(e.Error);             };             // Register a handler for the SaveEditsFailed event             fl1.SaveEditsFailed += (sender, e) =>             {                 // Report failure                 Console.WriteLine(e.Error);             };             Console.WriteLine("Calling Initialize on Thread " + d.Thread.ManagedThreadId.ToString());             // Call Initialize method (in a map/UI scenario this call would be handled by the Map).             fl1.Initialize();             // Need to call Dispatcher.Run             Dispatcher.Run();                     }     } } Cheers Mike ... View more

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.ArcGIS.Client.Local.LocalFeatureService.html. 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 ... View more

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 ... View more

Hi, Yes, the ArcGIS Runtime SDK for WPF can be used in an offline mode. Depending on what functionality you need you may need to use local services which you can create programmatically via the API based on "packages" - see http://resources.arcgis.com/en/help/runtime-wpf/concepts/index.html#/Packages_used_by_ArcGIS_Runtime_SDK_for_WPF/01700000005v000000/ for more information. The LocalGeometryService does not need a package - that can simply be started/stopped as required. Cheers Mike ... View more

Hi, The workflow for this is to create a LocalFeatureService, which will spawn both the feature service and the parent map service then add a ArcGISLocalDynamicMapServiceLayer for display using the local map service and add an ArcGISLocalFeatureLayer using the local feature service with the Mode property set to SelectionOnly. There's a SilverLight sample which demonstrates this: http://resources.arcgis.com/en/help/silverlight-api/samples/start.htm#EditToolsSelectionOnly. Cheers Mike ... View more

Hi, The accelerated display should work with just a basic license. Can you provide some more details about what you've tried? - Where are you making the SetLicense call? - Is your application using a deployment or the central developer runtime? - What layers are you initializing? Cheers Mike ... View more

Hi, To add a temporary point to the map you should use the GraphicsLayer class: http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.Graphic.html. When you say X,Y coordinates, if you mean screen coordinates you can use the Map.ScreenToMap method to convert: http://resources.arcgis.com/en/help/runtime-wpf/apiref/ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.Map~ScreenToMap.html. The map coordinates should be in the same coordinate system as the map but the map will reproject them if it needs to. Cheers Mike ... View more

Hi, The Map Package (.MPK) file is compressed but it's only unpacked the first time it is accessed via a LocalMapService. After that, the LocalMapService will be using the previously unpacked MPK contents from disk (at V1.0 it's in your user profile under Documents\ArcGIS). Each time the LocalMapService starts it does still check whether the MPK file is more recent that the contents of the existing unpacked package. Therefore, usually the only activity which can take a noticeable amount of time when you start the application is the LocalMapService startup. It is recommended that you do this as part of your application startup (e.g. whilst a splash screen is displayed or perhaps whilst the user is logging in or performing some other activity so that the LocalMapService (and the ArcGISLocalDynamicMapServiceLayer it supports) is ready as soon as the user is ready to begin interacting with that content. This will mean creating and starting these services in code rather than defining everything in XAML, but we did want to support both use cases. Cheers Mike ... View more