Latest Contributions by JimmyKnowles

Well, now this is happening to a normal feature service. I just published a simple feature service, added it to the same map and when I try to download a map, it prompts me for credentials for that layer. I also added it to a new map where that is the only layer in the map, still prompted for credentials. I tried the workaround of creating a hosted feature layer view, but that also prompted for credentials.  This isn't happening on iOS or on Windows. Anyone else seeing the Android version of Collector prompt for credentials to download a layer? ... View more

Kory - I did some more testing and I'm pretty sure my conclusion is that the 'Import XML Workspace Document' tool will not make changes to existing domains in an fgdb. It doesn't have an issue making attribute changes. Here's what I did to test this: Test domain change: Removed domain value from domain in exported XML from Pro (I worked with XML produced by Pro because I have had issues with XML produced by Enterprise Architect. It's a great tool, but doesn't do a great job producing fully compliant XML. I wanted to take this out of the equation.) Imported modified xml into existing fgdb Without closing Pro, change did not show up in Domains View even after closing and reopening Domains View Closed Pro, reopened Pro, added fgdb to project, opened Domains View, change did not show up Created new empty fgdb Imported XML into new empty fgdb Change shows up Test attribute change: removed attribute from FC in exported XML from Pro imported modifed xml into existing fgdb change shows up immediately in Fields View This may be the expected behavior. If it is, I think the warning or the documentation should let the user know that domains won't be updated with this tool. I've attached the XML exported from Pro if you'd like to look into this further. Using X-ray in ArcCatalog it identifies some issues with the XML that Enterprise Architect generates and since I tested that the issue exists with the XML exported from Pro, I think it makes sense to use 'good' XML for any further testing. This isn't a very simple fgdb (9 feature classes, 1 table, 9 relationship classes, 35 domains), so it might be worth testing with a simpler fgdb. I'm done playing for now since I have my workaround. Okay, I can't help myself....I changed my mind and decided to test with a simple fgdb. Here's what I did: Test domain change created fgdb, one FC, one domain (3 domain values), one field using that domain, two additional fields exported to XML from Pro edited XML to remove one of the domain values imported XML to existing fgdb change was not reflected in fgdb in Domains View created empty fgdb imported XML into empty fgdb change was reflected in formerly empty fgdb in Domains View Test attribute change edited same XML to remove one of the fields imported XML to existing fgdb change shows immediately in Fields View So, conclusion is the same...'Import XML Workspace Document' doesn't appear to modify existing domains, but will modify fields. ... View more

Hey Kory - thanks for finding that idea for me. My searching skills were a little sub-par today  Glad it's not just me with this problem or a similar one. Though after some further testing, I think they are two separate problems. One is with domains not refreshing after using the 'Table to Domain' tool, the second being domains not updating using 'Import XML Workspace Document' on an existing fgdb w/ existing domains. 1. Yes, I have opened and closed Domains View. Same behavior. 2. Yes, there are map layers that have the fgdb as the data source. And when I use those layers, they do not respect the changes. For example, I just created symbology from an updated domain and it used the old values. 3. If I open a new instance of Pro, no map, add that fgdb as one of the project's databases, Domains View still shows the 'cached' domains. This had the existing instance of Pro open with my original project w/ the map. I also closed all instances of Pro, and repeated # 3 above. Same behavior. I was wrong in my initial post, when I export back to xml, the changes are not reflected.  I tried 'import XML workspace document' in ArcCatalog as well and it complains that there are existing feature classes and wants to create duplicates of everything appended w/ '_1'. It doesn't seem to have a problem with domains. Pro gives a warning that everything will be overwritten, but it appears it's not overwriting the domains. It does update any attribute changes that I make. All of this leads me to believ that the 'Import XML Workspace Document' tool is not overwriting the existing fgdb even though the warning says it will do that. I think my workaround will be just to write a python script that deletes all layers, tables, then domains, and then imports the xml workspace document. The help for the 'Import XML Workspace Document' mentions overwriting and I have that checked in options. Maybe this is expected behavior, but it would be nice to have some feedback letting the user know that existing domains will not be updated, but attributes will. My workaround is to use a python script that deletes all layers, tables, then domains, and then imports the xml workspace document. Works like a charm and keeps me from having to update the source of layers to a new fgdb every time I make changes.  ... View more

Update: This BUG was updated on 27 Nov 2019 and now shows up in the product plan. Not sure when it will get implemented. In the meantime, this workaround is going to help me. Add a custom Arcade expression to the pop-up and this will show up in the attribute table in both the web map and the web app. Instructions are in the following thread. Field not showing in AGOL table  ... View more

Kory & Tristan, I tested this in 2.4.2 and using Arcade in the 'Calculate Field' GP tool, it yields the same results as we've seen previously. It appears Tristan is using Attribute Rules. I can confirm that when using Attribute Rules, an Arcade expression of just 'return' does indeed return Null for both Text and Double.   I haven't needed this since almost exactly a year ago, so didn't even think if attribute rules would have helped or not. ... View more

Shaun, thanks for your follow-up response. I was more curious why it wasn't working since it seems that those emoji characters are supported in general in Pro (demonstrated by the fact that they show up fine in the Arcade expression box). I don't think I'll be using it this much so the use of the Segoe UI Emoji font will likely be enough, no need to ask around. If I do need more functionality, I'm glad to know that some good alternatives exist for using emojis as you described. Doing it in the label was nice since we could combine the emoji with other information. ... View more

Shaun, that did the trick. Thanks for your help. Does that mean that I'm restricted to that font if I want to use emojis in labels in Pro? ... View more

Mike, thanks for the workaround. For my needs, this will do the trick! ... View more

Thanks Mike. That does appear to be the case. Thanks for confirming that I wasn't missing anything. ... View more