|
POST
|
Barbara, this might help: https://github.com/esri/arcgis-pro-sdk/wiki/ProGuide-content-and-image-resources It covers the various options for referencing images in your add-in. Pay close attention to the "image" Uri syntax - in particular the "/" - is it forwards or backwards "\"...? Notice for AddinContent it is backwards "\".... One option that is not in that guide, but, seeing your post, I will add it, is to use something called a pack Uri. (cm - actually, on review, there is a section there called Referencing images from Arcgis Pro but I will expand it). A pack Uri is a way of referencing content that is contained, as a resource, ~within~ an assembly. A pack Uri looks like this <Button ...
largeImage="pack://application:,,,/ArcGIS.Desktop.Resources;component/Images/GenericButtonBlue32.png"> (and is a bit unfriendly). If you choose to use a pack Uri from your ~own~ add-in (notice how this one references "ArcGIS.Desktop.Resources" which is the Pro assembly that contains all of the Pro icons) you would do the following: Add the image to your add-in project. Assume you add it to the folder called "Images". In Visual Studio, on the image properties, set its "Build Action" to Resource Change the pack Uri as follows - let's make an assumption that your add-in assembly is called "MyAddin.dll" and the image you added was called "MyImage32.png" and was added into the add-in Images folder: <Button ...
largeImage="pack://application:,,,/MyAddin;component/Images/MyImage32.png"> One final point: After following these instructions your image may still not show (eg on the button). Why? Well, let's assume that the issue is not syntax, the issue is not incorrect Build Action or path or other user error. Everything is exactly correct but the image still does not show.... The answer is because of delay loading. Add-ins, by default, are delay loaded. This means that they do not actually ~load~ until a user activates them - usually by clicking on a button that is contained within the add-in. At that point in time, and only at that point in time, does the add-in assembly load. Delay loading is done as an optimization technique to only load those assemblies as they are needed....on demand, so to speak....and not all at once at startup. What this means for you is that the image you added as a Resource into your add-in assembly will not have been loaded (until the add-in is loaded) when the Pro ribbon is shown - In other words, you can "see" your button (sans image) but the add-in behind it is, in fact, not loaded and so neither are any of its resources - to include the button image!!!. Alright, well great....but I still need to know how do I get my image loaded and shown on the button on the ribbon! You have three options: Force your add-in to load at Pro initialization. In that case your add-in assembly will be loaded and the image will be immediately available. To do this set the module "autoLoad" property in your Config.daml to "true" (it is false by default). Reference an image in a dll that is loaded at start-up (such as the images found in ArcGIS.Desktop.Resources.dll) - Notice that this is what the Pro SDK Item templates do - by default all images are referenced from the Pro resources dll. Use AddinContent as the Image "Build Action". AddinContent is a custom build action specifically designed to deal with the delay loading characteristics of add-ins and is installed with the Pro SDK. In a nutshell, if you use "AddinContent ", the image will be referenced from within the add-in zip archive and not from within the assembly. In other words, Pro does not have to load the assembly to access the images built as "AddinContent". Note that the path separators for the image path point backwards "\". The downside with AddinContent is that Images with that build action type, because they live in the zip archive and not in the dll as resources, can only by referenced in the Config.daml and not in a WPF User Control, for example (via a pack Uri). It is a custom content type (we, "Esri" implemented to support delay loading) and is not a WPF resource type. Again, consult https://github.com/esri/arcgis-pro-sdk/wiki/ProGuide-content-and-image-resourcesfor more information and I will update that document to cover provide more details on use of pack Uris in the Config.daml.
... View more
01-17-2020
10:07 AM
|
4
|
0
|
11064
|
|
POST
|
Go to https://solutions.arcgis.com/defense/help/military-symbology-styles/ and download the latest version(s) (100.6). Yours looks to be quite old and pre-dates the use of Arcade, etc.
... View more
11-18-2019
08:33 PM
|
0
|
0
|
4566
|
|
POST
|
Note the instructions in steps 2 and 3 from the github: 2. Open the copy of the mil2525c.stylx in an SQLite database editor.
3. In the meta table, .... So you will need a SQLite database editor. The one most people use is called "DB Browser for SQLite". Download and install it (or another one of your own choosing). Open the stylx file in the browser. Open up the "meta" table and change the value for "readonly" to be "false".
... View more
11-18-2019
01:18 PM
|
0
|
3
|
4566
|
|
POST
|
Hi Max, this has been added to 2.5. Look for "public static CreateProjectSettings GetDefaultProjectSettings();" on the Project class. Example usage: Project.CreateAsync( Project.GetDefaultProjectSettings());
... View more
09-18-2019
01:10 PM
|
2
|
1
|
1277
|
|
POST
|
Hi David, your add-in Module still loads even if you have not enabled your add-in (via, I am assuming, an IExtensionConfig implementation?). Assuming you are using IExtensionConfig, your module always needs to load to allow you, the add-in developer, to respond to a licensing check from the Pro app (which is usually triggered when the user attempts to "check" or enable your extension via the licensing tab on the Pro backstage). This means that your add-in will autoload as normal, if that is what you specified in your config.daml, and can listen to the OnReadSettingsAsync callback regardless of its "State" returned from IExtensionConfig. Therefore, the add-in module can retrieve the stored defaults via the callback "as usual" whenever a project opens - even though, to the "outside" world, you may be showing its capabilities (tools, buttons, etc) as disabled.
... View more
09-16-2019
04:13 PM
|
0
|
0
|
1947
|
|
POST
|
Alex, First, the purpose of the EditOperation.EditOperationType parameter is to allow callers of the edit operation to restrict all participating datasets in the operation to have either LONG or SHORT transaction semantics (depending on what you set it to). The default is NULL which is what we call "MIXED" - as in datasets with LONG and datasets with SHORT semantics can be "mixed" together in the same edit operation. This is explained here: ProConcepts-Editing#edit-operations-and-long-and-short-transactions Second, given my explanation above (and in the article referenced), the use of the EditOperation.EditOperationType, therefore, is not to ~change~ the transaction semantics - that is not possible. It is to ensure that all of the participating datasets are of the same transaction semantic specified (LONG or SHORT). If there is a mix, when either of LONG or SHORT is specified, an exception is thrown. If you specify LONG and attempt to edit a SHORT transaction semantic dataset you get a generic error along the lines of "the edit failed because you tried to edit non-versioned data" and conversely if you specify SHORT and attempt to edit a LONG transaction semantic dataset you get a generic error along the lines of "the edit failed because you tried to edit versioned data" - which is the message you got - File Geodatabase is LONG and you specified a restriction of SHORT. [There is a table in the same article that I reference above that gives you the transaction semantics of a given datastore based on its characteristics]. Third, you ask "Is it because the edit operation automatically spans all the workspaces being accessed"...if I reword your question slightly to "Is it because the edit operation automatically spans all the workspaces of all datasets being accessed in the edit operation", then the answer is yes. An edit session is established for each workspace (datastore we call them in Pro) with LONG semantics. No edit session is established for workspaces enlisted in the edit with SHORT semantics (because, by definition, there is no such thing). This can lead to a confusing UI experience if the user is not aware of the characteristics of the data they are editing. The LONG transaction data is undo-able and requires an explicit save to commit it. The SHORT transaction data is automatically committed ("saved') and is not undo-able. Thus, if the user is editing MIXED mode data (the default) and goes to undo one or more edits then only the LONG transaction data edits can be undone. The SHORT transaction data changes will already have been committed. To allow 3rd party developers to enforce consistency in the UI during editing when the TOC content is "mixed" (everything undoable, nothing undoable, save edits required, save edits not required) the EditOperation.EditOperationType parameter was added. Fourth, you ask: "All the geoprocessing calls are using the GPExecuteToolFlags.None flag so no output is being added to the map. The code runs successfully but no features are written into the feature class. When I close Pro, I get the "Do you want to save the edits?" prompt, and if I click Yes, the features do appear in the feature class. It looks like the edits are being added to the Pro edit stack. Should this be happening when I am using the callback to create features? How can I have the edits saved automatically?" Let's break this down: - "All the geoprocessing calls are using the GPExecuteToolFlags.None flag so no output is being added to the map. The code runs successfully but no features are written into the feature class" - GP either starts a new edit session on the File GDB or enlists in an existing edit session if one has already been started. Presumably because of the flag the edits are not showing up in the table pane but they are "there", waiting to be committed. - "When I close Pro, I get the "Do you want to save the edits?" prompt, and if I click Yes, the features do appear in the feature class" File Geodatabase is LONG. An edit session was started and an explicit save is required to commit the edits. "It looks like the edits are being added to the Pro edit stack." - File Geodatabase is LONG. Edits are undo-able "Should this be happening when I am using the callback to create features?" Yes. The callback will start or enlist in an edit session on the File GDB "How can I have the edits saved automatically?" You must explicitly call Project.Current.SaveEditsAsync(). Note: This will commit all edits currently pending on all edit sessions. [It will also terminate all edit sessions on all datastores.] This is the same behavior as if the user clicked Save Edits on the UI.
... View more
09-10-2019
10:21 AM
|
1
|
1
|
2273
|
|
POST
|
I suspect this is the root of your original problem: var rowCursor = layer.Search(myGeometry, SpatialRelationship.Crosses); You are using a recycling cursor. Change to a non-recycling cursor (access this off the feature class). With a recycling cursor, repetitive calls to op.Modify with rowcursor.Current will get overwritten by the following "current" feature. (note: the last feature in your selection was probably getting successfully modified). //This is a problem with a recycling cursor when in a loop. cutOperation.Modify(rowCursor.Current, fkzFieldIndex, "MyNewFKZ");
... View more
08-21-2019
10:32 AM
|
0
|
0
|
2239
|
|
POST
|
Than, start here: ProConcepts-Framework#introduction-to-daml-desktop-application-markup-language
... View more
07-19-2019
09:22 AM
|
0
|
1
|
3036
|
|
POST
|
Matt, this is a bug. It will be fixed in the next release - 2.5
... View more
07-18-2019
01:46 PM
|
0
|
0
|
1743
|
|
POST
|
Than, you are almost there 😉 You have some copy-paste baggage. Change this '<updateModule refID="esri_mapping">' to this '<updateModule refID="esri_geodatabase_module">' and you will have it.
... View more
07-18-2019
11:34 AM
|
1
|
0
|
3036
|
|
POST
|
Than, This is how I would find a context menu id by way of example. Let's assume that you want to add a new item to the "Databases" context menu in Catalog pane (sorry, I am not familiar with "Research Data" context menu) First, make sure this option is checked on: Go to the context menu you are after and hover over one of the core buttons that is on it (in my example I use "Databases" folder context menu): With the "Show Command IDs" option checked on you get the daml id for the particular button you are hovering over displayed in its tooltip. Go to: https://github.com/esri/arcgis-pro-sdk/wiki/ArcGIS-Pro-DAML-ID-Reference In your case I would try "ADGeoDatabase.daml" first - which also happens to be the .daml file I will use to find the "Databases" context menu. Click on the "Click this link to view ADGeoDatabase.daml" link on the github to get to the "raw" daml. Hit Ctrl-F and type in the daml id you captured from the desired context menu button: Step through occurrences of the daml id until you get to the containing menu you are after: Cycle through the other daml files if you don't get a hit in ADGeoDatabase.daml. Record the daml id (GDBContainerMenu in my example).
... View more
07-17-2019
05:15 PM
|
0
|
2
|
3036
|
|
POST
|
I was answering this: >>My question is how come SDK automatically updated to 2.4??<<
... View more
07-17-2019
10:41 AM
|
0
|
1
|
3872
|
|
POST
|
Hi Naresh, this is explained here: ProGuide-Installation-and-Upgrade#upgrade-arcgis-pro-sdk-for-net
... View more
07-17-2019
09:47 AM
|
0
|
3
|
3872
|
|
POST
|
sounds like the Microsoft Visual C++ redistributable package is missing from your server machine https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
... View more
07-07-2019
05:11 PM
|
0
|
0
|
3169
|
|
POST
|
Max, the issue to me looks like you are not specifying a cell size. The resulting cell size of the raster is 10600614 which matches the dimension of the raster. I do not know the significance of that number (i.e. why is it used as the default cell size). However, if I do specify a cell size explicitly (eg "90" or "180" ) then the extent of the layer is correct (as, in, it is a proper extent). As the cell size, in this case because of the projection being used, is in decimal degrees and the WGS projection is wider than it is tall, I assume that the maximum possible cell size will be "180" while still retaining a "real" spatial extent. For example, using your same settings and a cell size of 180:
... View more
06-17-2019
11:26 AM
|
0
|
1
|
3410
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-19-2026 10:29 AM | |
| 1 | 04-29-2026 02:06 PM | |
| 1 | 01-08-2026 02:03 PM | |
| 1 | 01-08-2026 02:15 PM | |
| 3 | 12-17-2025 11:33 AM |
| Online Status |
Offline
|
| Date Last Visited |
4 weeks ago
|