Latest Contributions by CharlesMacleod

Hi Shohei, So let me also provide some guidance. First: the documentation you reference is not clear on use of DelegateCommands and we need to do a better job of explaining them and we will do that for 1.2. Second: the DelegateCommand update must be a property, not a method. It must be a property that returns bool. You can actually see that in the Module1.cs class file that Thomas points out in the sample in his reply. This is a subtlety that is not clearly documented. So, to get your code working please try this implementation: internal static void OnMyCustomButtonClick() {             System.Diagnostics.Debug.WriteLine("OnClick called");         }         internal static bool CanOnMyCustomButtonClick {             get {                 System.Diagnostics.Debug.WriteLine("OnUpdate called");                 return true;             }         } Notice that CanOnMyCustomButtonClick is a bool property. Also, I have not used QueuedTask as this is not really necessary and would be inefficient in the Update property given the frequency with which it is called but I get it that you were probably just experimenting with different API characteristics and what-not in your code. Last, to a point Thomas raises with regards to conditions and also an Update implementation. Use of the condition in daml is much more efficient than coding update logic (whether via an OnUpdate override or a "Can..." update property. However, if you do have both, the condition in daml and are updating your enabled state via Update code, then the Update code wins with one exception: The initial enabled state of the button as shown on the ribbon. Before the button has been clicked, the Framework will use the condition in the daml to show its initial enabled state. Once the button has been clicked then the button state is controlled by its Update logic and the condition is ignored. You can observe this behavior with your implementation: Return false from your update property and keep your "esri_mapping_onlyFeatureLayersSelectedCondition" condition in the DAML. Before clicking the button, select and unselect a feature layer in the TOC. You should notice the button's enabled state toggling based on the condition true/false. Once you click the button it will always be disabled regardless of the condition. (Note also that your OnClick logic is never called....why?) This would be akin to coding this for an OnUpdate override: protected override void OnUpdate() {             this.Enabled = false;//disable the button the moment it is clicked.         } ... View more

Hi Shohei, To add the ids to your project use the ArcGIS Pro SDK for .NET Utilities, Pro Generate DAML IDs utility. It is shown here. After you have run it, the ids will show up in Intellisense within a csharp or vb code window. At 1.2 we will include a complete listing of DAML ids on the  ArcGIS Pro SDK wiki ... View more

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