Latest Contributions by CharlesMacleod

Hi Joseph, I wrote one for you. Please go to the Pro community samples on the github at https://github.com/Esri/arcgis-pro-sdk-community-samples/tree/master/Geometry/CoordinateSystemDialog There is no API call currently to get the list of SpatialReferences so I had to use arcpy.ListSpatialReferences. We will look at adding that capability into the DotNET API for Pro at 1.3 ... View more

Hi Domenico, this is definitely a bug. Thanks! We will fix at 1.2. "projTransFromSRs" should be returned but, of course, its Transformation property will be null in this case. Note: "==" is not overloaded so the false is because the SRs are not the same instance. Please use "IsEqual". Said another way: var sr1 = new SpatialReferenceBuilder(SpatialReferences.WGS84.Wkid).ToSpatialReference(); var sr2 = new SpatialReferenceBuilder(SpatialReferences.WGS84.Wkid).ToSpatialReference(); sr1 == sr2 //False! sr1.IsEqual(sr2) //True! ... View more

Hi Joseph, functionality similar to what you have with IConversionNotation, etc. in 10x is currently not available in the Pro API. We will add support to the Geometry API (ArcGIS.Core.Geometry) for points conversions (eg MGRS, USNG, GARS) at 1.2 or 1.3 ... View more

Hi Jens, so my replies: >>>This makes ArcGIS Pro actually to kind of a single threaded application, as soon as it comes to data access In Pro, the threading model is simplified for developers so all you have to worry about is a simple "binary" condition: Foreground -or- Background. Pro handles the rest. Internally, Pro delegates work submitted on the QueuedTask to its own internal thread pool and makes sure that any changes are propagated to all instances of Pro's internal state on each of its threads. Which thread your code actually runs on is an internal detail controlled by QueuedTask. You submit your "job" (work defined in the lambda) to QueuedTask and QueuedTask does the rest. Specifically with regards to databases the same rules apply in Pro as with any database application - Enterprise databases are throttled by their own internal connection pools, which user credentials are used to connect and perform edits, write locks, etc.,etc. File gdb is single user access only regardless of threading behavior of the application. You can read more of Pro's internal threading behavior here: https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Framework#the-arcgis-pro-internal-threading-model >>>>>Question is: Is this supported in any way? I do understand, that I will run into problems as soon as I try to pass objects from one thread to another. Updating data might also become critical, as there might be no synchronization context. But if I stay in a read-only context, is it ok to create "my own" geodatabase object in "my own" thread? Yes it is ok. The rules are simple: it must be instantiated on an STA (which QueuedTask provides) and you must ~always~ access the class on the same (STA) thread upon which it was created. Generally this means that the lifetime of your class instances should be strapped to the scope of the lambda within the QueuedTask.Run (or System thread in the case of CoreHost). So when the lambda goes out of scope all the instances (like Geodatabase, FeatureClass, etc) are disposed. Creating multiple copies of the same geodatabase across multiple STAs should work in theory for RO access (assuming underlying database resources are sufficient)  but is not something we support currently. Last, with regards to the CoreHost samples, They are running on top of the Core.Data API ~outside~ of Pro so the Framework is neither instantiated nor available. As such, the sample is using an STA from the system thread pool (because QueuedTask is ~not~ available outside of the Framework). It may come as some surprise that System Task is MTA and so is not suitable. The sample, therefore, uses a utility method to.spin off a System.Thread configured as STA yet wait on a System.Task for completion (I copied and pasted that code from stackoverflow - I think I put the url in the comments of the sample). At 1.2 we will provide a class called QueuedWorker for use in CoreHost scenarios that will have a Run method similar to QueuedTask.Run and should simplify that pattern (ie make it very similar to code you would write inside an Addin in Pro without resorting to using a System.Thread...unless you wanted to ;-). ... View more

Durga, Thank you very much for your interest in the ArcGIS Pro SDK.  We have attempted to address many of our users questions w.r.t the Pro SDK in our ArcGIS Pro SDK FAQ which can be found at: http://github.com/Esri/arcgis-pro-sdk/wiki/FAQ . We will continue to update this FAQ across future releases of ArcGIS Pro. With regards to Engine vs Runtime, Runtime is absolutely a replacement for Engine. A comparison of the two products and related discussions can be found here: ArcGISEngine vs ArcGIS Runtime Q&A With regards to the future of these products please consult the product lifecycles which can be found at: http://support.esri.com/en/content/productlifecycles For example, notice that 10.3.1 is not retired until December 1, 2020. That means that the corresponding SDKs for desktop 10.3.1 (Arcobjects, Arcengine) will follow the same support plan and lifecycle (meaning that the 10.3.1 releases of this product are not retired until Dec 1, 2020 also). Runtime likewise posts its lifecycle documentation there too. When 10.4 is released it too will have a lifecycle which will include the ArcObjects and ArcEngine. Likewise for 10.4.x and so on. On the choice between Runtime and Pro, they serve different purposes. Runtime is, by its nature, a development product. It can be used to write applications from scratch or embed Esri technology in GIS and Non-GIS applications (whether on mobile, tablet, desktop). Pro is an application. It's functionality is dictated by its feature functions ~however~ it can be extended with its .NET SDK (or automated with its python SDK). Customization of the desktop platform (and, to an extent, Server platform) continues to be supported with ArcObjects. ... View more

There is no such API method. ... View more