Latest Contributions by alex_friant

@SebastienPelletier - Thanks for sharing that Bug report. I think I kind of figured out why Experience Builder (XB) is screwing things up with Scroll zooming after black boxing this issue. First, I created a global "Level of Detail" (LOD) layer (shared publicly so you can try) so I could see what standard Level of Detail (0-23) you are between while at any particular arbitrary scale. Second, if you use that layer in a Map Viewer map, you can see clearly that Map Viewer respects each "Scroll" event as a single LOD step. Third, if you use that same layer in a map consumed by XB, you can see that XB is doing something different, but what? To figure that out, I changed my Windows 11 Mouse settings under Scrolling to change the number of "lines" a scroll event would scroll a document from the default of "3" to "1" line. Back in XB, you can see instantly, while scrolling now, that the LOD has some arbitrary scale steps configured that are much "narrower" than the standard LOD scales. There appears to be about 4 scale steps between each LOD cut off. To be precise, there are exactly 94 scale levels utilized by XB. If you're using Windows 11 or 10's default Mouse Scroll "3 line" setting, you'll usually end up (depending on where you start) with about 1 or 2 scrolls to change from one standard LOD to the next in XB. But this is not true in Map Viewer! Map Viewer doesn't care what your OS Mouse Scroll Settings are set to - it only looks at whether or not your mouse scrolled once. The bug, it appears, is twofold: XB has 94 scale steps, not the standard 24 XB isn't respecting mouse scrolling events as single LOD step changes like Map Viewer does, rather XB is receiving its scrolling events from the "# of lines" setting in the OS (or mouse driver). (The following is speculation) This difference between Map Viewer behavior and XB behavior is probably due to Map Viewer JavaScript listening to 'scroll' events, and XB is listening to 'wheel' events and having the setting "event.deltaMode === 1", which has the app listen to the OS settings. ... View more

😢 okay ... View more

The colon ':' just after #data_s=id needs to be encoded to %3A so it looks like this: #data_s=id%3A instead of this: #data_s=id: Conversely, the %3A just after the 'search_status' parameter needs to be a colon ':' so it looks like this: search_status: instead of this: search_status%3A The final URL should look like this: https://myportal.org/portal/apps/experiencebuilder/experience/?id=4224xxxxxxxxxxxxx982#data_s=id%3AdataSource_1-18fc5181f68-layer-16-0&widget_2=search_status:%7B%22searchText%22%3A%221234%20Executive%20Park%20Blvd%22%7D This is a breakdown of why some colons are encoded or not:   ... View more

We'd love to see Esri's photo-enabled applications (QuickCapture, FieldMaps, Survey123, etc.) include built-in watermarking capabilities that would let the form and map designers easily add timestamps and custom text (i.e. coordinates, name of app & user ingesting) to photos. This could work beautifully as headers, footers, or overlays, giving teams the flexibility they need for documentation and branding. Even better, imagine if organizations could create standardized watermark templates at the enterprise level - similar to how organization themes work now. Designers could then simply select from these pre-approved templates, ensuring consistency across projects while saving time on setup. This would streamline workflows and give organizations better control over their visual standards during data collection. ... View more

Background: I was gratefully advised by Pro-West Associates that they have seen this issue before, and it appears to be related to if the user account experiencing the RuntimeError has signed into ArcGIS Pro before. The issue is tied to the Windows Registry, and while I can confirm that's the case with our user experiencing issues, it's not always the case, only that the fix lies in the registry. I had two other User accounts on the same server that had also opened ArcGIS Pro, but import arcpy worked just fine for them when using the ArcGIS Server Python 3 environment. So, replicating the issue is difficult. These are the steps taken to solve the RuntimeError for that one user we needed to be able to use arcpy in the ArcGIS Server Python 3 environment: Make sure ArcGIS Pro is uninstalled (I also had ArcGIS Desktop 10.8 uninstalled as well, so if you still have that installed, you may want to take that into consideration at step 5 below) Sign in as user that was experiencing the issue of RuntimeError during import arcpy Open the Windows Registry Editor  Danger! Only do these steps in an environment you can recover catastrophic failures with, as Windows Registry is a core component of the Windows OS and can cause instability or corrupt the Windows OS. Proceed at own risk and if you know what you are doing! Note the settings for [Computer\HKEY_CURRENT_USER\Software\ESRI\ArcGISPro] are:                       Make those > ArcGISPro settings look like so:                                     Close Registry Editor Sign out the user from Windows, Sign the user back in  Test using Server’s Python 3 command prompt:                                                                          Reinstalling ArcGIS Pro after this point still results in a success as above. We will not have that user sign in to ArcGIS Pro out of concern that it might cause issues again (we've burned too much time on this issue at this point and must march forward.) I hope this solution works for others - it was hard to discover! ... View more

@ShaunWalbridge - Great suggestion, because I looked for it and bingo: https://support.esri.com/en-us/bug/running-python-scripts-from-within-the-arcgis-enterpris-bug-000128742 I haven't tested the work around, but I'm about to try... UPDATE: Resolved The work around in that bug report didn't work for our situation. The issue persisted, even after uninstalling ArcGIS Pro all together. However... I was able to resolve the issue and document it. I'll post that next... ... View more

Thanks for the tip - that seems strange if true. The Pro installation should have nothing to do with the ArcGIS Server installation. If it does, then that means Pro is interfering with the normal operations of ArcGIS Server, which is concerning. I'll give it a shot to see what I can figure out/duplicate the suggested work around. ... View more

Did you ever figure this out? I'm running into the same issue with propy.bat in ArcGIS\Server\framework\runtime\ArcGIS\bin\Python\Scripts One machine, two different accounts. Account#1 Server propy.bat works just fine when I try to import arcpy. Account #2 Server propy.bat opens but import arcpy has RunTimeError: The software is not authorized for use. Being signed into ArcGIS Pro has zero effect on the outcome, on either account. Server should just be licensed to use arcpy, right? ... View more

I support this idea. In its current incarnation, you need to make sure your basemap and/or symbology aren't heavily yellow, otherwise the flash doesn't pop the way you need it to. It would be nice to be able to change the flash look, including color, duration between flashes, and number of flashes. ... View more

You can now use a Search Widget in XB to pass the search parameter, you just need to specify the data source: https://doc.arcgis.com/en/experience-builder/latest/build-apps/url-parameters.htm#ESRI_SECTION3_7153181A580C4B4AADF0166A57C1ACA0 Here's an example decoded URL, you would just need to encode it for a browser to accept it: You can use the Share Widget to generate a long-form URL to include parameters to learn things such as widget ID and datasource ID.     ... View more

I just ran into this issue building out my first big application in Experience Builder. This feels like a fundamental UX which everyone has learned to expect. Bumping to hopefully get this implemented. ... View more

I got addresses to be placed on the map by constructing the CSV like this: address "123 Main St, Anytown, ST" "555 Washington Ave, Othertown, CA" ... View more

Product Development team, please make this possible! 🙏 We are crossing out of an old custom WAB SDK app to XB on AGOL, and our users are going to miss this functionality when we do.  ... View more

@RandyCasey - There is certainly an argument to be made for Pro to improve how it should provide the user a way to easily determine which specific map & layer a table is associated with. I suggested color coding up thread. The main issue you pointed out to the idea of using the multiple Pro projects approach was having different geodatabases. However, you can change the default geodatabase for each Pro Project to point to the same geodatabase. Not sure if having them all open at the same time would cause edit lock issues. So maybe that’s a no go. Another workaround approach is to use just one Pro project, but name each layer with some convention that tells you which map a table is associated with. MAP: Editng Editing - Hydrants Editing - Address Points MAP: Analysis Analysis - Hydrants Analysis - Address Points Something like that. This way you can always see which map a layer is associated with. Now it would be cool if there was some programmatic option available in a Pro project to automatically display table titles in such a way so we didn’t have to redundantly put the map name into the actual layer name, but it could function as a work around in the meantime.   ... View more

I kind of feel like making multiple Pro projects might be the solution listening to the workflows described in this thread. That way you can keep things organized how you want them and you know what map tables belong to because they are right there in the same Project app. Pro makes it tempting to load it with 8 maps and 32 layers and open them all, because you can. But that might not be the best approach if you need to look at all that at the same time. ... View more