Latest Contributions by BradleyThompson1

@ZeminDhanani Appreciate what you've shared so far. Hate to potentially ask you to repeat yourself but, when it comes to the specific windows you're concerned with, are you referring to only the highlighted red progressor window in your screenshot? Or are we concerned with multiple different types of windows including that one?  ... View more

@-_- - have an update for you that should serve as a temporary workaround:  From the 'Customize the Ribbon' page, assign "Ctrl + D" to "esri_mapping_clearSelectionButton", and then assign a different shortcut (as long as it's not "Ctrl + D") to "esri_core_editDeleteButton".  Navigate to %LocalAppData%\ESRI and open the ArcGIS.Desktop.Config.daml file in a text editor of your choosing. For both the "esri_mapping_clearSelectionButton" and "esri_core_editDeleteButton" commands, change their <insertAccelerator> tags in this .daml file to <updateAccelerator> instead. Save your changes and close your text editor. Re-open ArcGIS Pro & navigate to 'Customize the Ribbon' in Options. Search for & find "esri_mapping_clearSelectionButton" - confirm that the updated shortcut is now reflected in the window.    Please give me a heads up whether or not this resolves the issue temporarily for you - would be happy to review that ArcGIS.Desktop.Config.daml file on my end if it does not.  ... View more

@-_- Thank you for bringing this to our attention my friend - we've been able to reproduce this problem in-house, and I've since logged an issue for our team to begin work on fixing the problem. This issue has been provided to Esri Support & logged as the following defect:    BUG-000158718 - ArcGIS Pro 3.1.x \\ Assigning and/or Changing a Command's Shortcut in the 'Customize the Dialog' Page of the Options Window Does Not Work   I don't believe this defect is public-facing yet due to how fresh it is, but in the next few days you should be able to review information attached to it from your MyEsri account (in the 'Support' section of the header on the main MyEsri page) and track its status there.    Thank you again for passing this information along; terribly appreciate your time & patience. I'll follow-up on this thread as we make headway towards a fix.  ... View more

All,  Thank you for your patience - despite the time that's passed, I've still been attempting reproduction of this issue on a weekly/bi-weekly basis as I review other Bugs and Enhancements that've been requested of my team.  So far, I have not been able to reproduce this problem on any of my test machines, including those I've re-attempted repro over RDP on. While debugging builds of ArcGIS Pro w/ Visual Studio on unrelated issues, I also attempted to be cognizant of this problem and remain observant in case I stumbled upon reliable repro. It's not that I haven't been able to reliably reproduce this issue; I haven't been able to reproduce it at all, which is frustrating to document.    Among those loosely-described attempts I've written above, and those attempts previously-documented by y'all in your posts prior, I've tried the following more specific attempts: - Launching Pro while unlicensed: This causes the 'Sign In' WebView2 Browser Control to appear, and two text boxes requesting my User and Password are present. This was repeated with various different software products (Office Suite, Chrome/Brave/Firefox, Notepad/Notepad++)  - I created a test project that had an Active Layout View open, along with the Element pane being docked to the right (on-top of the default placement of the Catalog pane). The Element pane was open & in focus within the client prior to closing the project because I had activated a Text Element in the layout and had inserted some text. Double-clicking the project & typing in some of the software products listed above didn't produce reliable reproduction.  - Both of the above over an RDP session that's set to full-screen   Regrettably because my attempts haven't produced something I can deliver to our developers, I'm unable to advocate for keeping BUG-000151047 open in our repo and have to close it as non-reproducible for the time being. That comes with the understanding that if new repro steps appear that can reproduce the behavior on a Support Analyst's and/or my test machines, it can be re-opened for investigation without issue. Terribly dislike having to close this bug after so much contribution from you folks, and collective time spent between you & myself getting this fleshed out. Sincerely apologize y'all, because I am strongly aware of how disruptive of a problem this is for you. One thing I'd like to say in passing (and would only recommend pursuing with the guidance of your IT teams, as this would impact all downloaded software for your Windows User Profile) is investigating the value of the ForegroundLockTimeout registry entry, found in your registry under HKEY_CURRENT_USER\Control Panel\Desktop. Since Windows 10 released this value should, by default, already be set to a hexidecimal value of 30d40 - if it's not, or it's set to a value of 0, you may find improvement with having it set to 30d40: https://superuser.com/questions/1113512/is-it-possible-in-windows-10-to-prevent-an-opening-application-from-stealing-foc/1401532#1401532 Again, if for whatever reason this value is not already set to 30d40, please consult with your IT staff before making any changes, on the off-chance you have client software downloaded that calls different application windows that require focus after launching - you wouldn't want to break that (I wouldn't want you to, neither).  Although the bug will be closed for the time being, I'll also continue attempting to test for this behavior while doing other work - if I stumble upon reliable repro myself, I'll re-open the bug and note this action here as well.   Thank you all for your time reporting this, and for providing information on your test steps and environments; I apologize that I couldn't catch this myself.      ... View more

Awesome, thank you - figured as much but wanted to be certain.  ... View more

Thank you both for the pointed information, terribly appreciate your time.   @BillyBuerger one quick question for clarity - when you're using Pro on a single monitor via RDP, am I correct in saying that Pro's focus over that RDP connection is being stolen from an app you've also opened over that same RDP connection? Focus-stealing isn't occurring when you're working outside of the RDP window, right?  ... View more

@BillyBuerger Thank you for your feedback - are you using Pro as part of a multi-monitor environment? It sounds like you're using a local machine and aren't connecting over RDP. Hate to be a pedant but as many of those bullet points that you can answer with specifics would be stellar if you have the time for it. Not positive if a pattern will become obvious, but given the variety of versions, configurations etc. I'm seeing I greatly want to try my best at finding one.  ... View more

Hi all,   The defect above has been placed in a 'Need Info' status as, despite our best efforts, we've been unsuccessful reproducing this in-house on a gamut of different machines, either physical or virtual. I'm working with the analyst who submitted the defect, Sara, to pose these questions to the end user this case was originally-logged against (if that particular user is on this thread, please do answer the questions to the best of your ability when she reaches out to acquire answers for them; don't hesitate to corroborate your answers here as well, but don't consider this valid in lieu of re-engaging Sara on your Support ticket). That being said, figured we'd do a bit of crowdsourcing to try and determine if any similarities begin to appear between affected parties.  To all affected parties, could you please answer these series of questions to the best of your ability and respond to this thread with them?  Are you using Pro on a physical machine, a VM, or either a physical/VM through RDP? What version of Pro are you using & encountering this problem with? Is this machine being used in a multi-monitor setup? If so: How many monitors? Does focus shift when Pro opens on your Main monitor (it should open there by default) and you're working within an application on a secondary/tertiary monitor; when Pro opens on your Main monitor and you're working within an application also on the Main monitor; or both? Does this issue only occur while Pro is launching in Full Screen mode, in Windowed mode, or both modes? Does this issue only occur while you're launching Pro standalone (i.e. searching for ArcGIS Pro in Start & launching it/double-clicking on the 'ArcGIS Pro' shortcut on your Desktop or Task Bar), when you're launching Pro via Opening a Project/aprx file, or both? Do you have any custom configurations or admin settings that load while ArcGIS Pro is launching? If so, do any of these configurations modify the Home page that displays after Pro launches? For reference, Manage Application Settings: https://pro.arcgis.com/en/pro-app/latest/get-started/application-setting-management.htm Do you have any custom Add-Ins installed? Are there any observations you've made that don't fall into any of the questions above? If so, please include them.  We'd be elated to get to the bottom of this one, but please do understand that the only reason we're kicking this back to information-gathering for now is out of necessity. Had this been caught on any of the test machines we took a stab at repro on, we'd have moved forward on this problem.  ... View more

The procedure I suggested, apologies for not being more clear. This may take some time to discuss on our end. If that ends up being the case, I'll consider alternatives that may be possible in the meantime.  ... View more

@JMitchell Hoo boy, I might've spoken too soon - this functionality doesn't seem to be working correctly. I'm still investigating and if this is the case, we're likely looking at not only a formal fix for 3.1 but easily a patch-candidate issue for 3.0.  I'll reach back out the second I have an update for you, this is a priority for my team at the moment.  ... View more

@JMitchell  *** [NOTE - 12/10/24] The following information regarding profile Roaming-to-Local profile redirection is INACCURATE; I sincerely apologize for the confusion caused. The erroneous statements provided below  is what we may intend on approaching as a formal implementation of this feature, as this has been widely requested and is on our radar. Complete mistake on my part, and I would like to re-iterate my apologies for the trouble.  ***  Having re-read the case details & your correspondence here, I'm isolating two concerns that I would consider separate problems: Performance Problems interacting with the application's UI; Inability to save user-specific customization settings that should persist from Pro session to Pro session (list of Recent Projects, Dark Mode, etc.) These issues may both be related to the fact that your Roaming User Profile is being saved on a network share, but I can't say that confidently. What I can say is that I'm pretty confident the following recommendations I'm about to make should help with resolving the emphasized bullet point above.  A large majority of all user-specific customization settings you can make in Pro are going to be saved to a user.config file. This file is saved in a user's Roaming profile in the following directory: %APPDATA%\Esri\ArcGISPro_StrongName_<string_of_alphanumeric_characters>\3.x.0.0\user.config   Normally this wouldn't be a huge issue but, for organizations that direct their users' Roaming profiles to be stored on the network and exert fine-tuned control over the shares that store them, odd problems like what you're describing can be encountered. Hate writing 'odd' as I'm not trying to sweep concerns like these under the rug, but a whole slew of new considerations arise due to a migration like this that're extremely difficult to account for all aspects of. Are they SMB or Samba shares holding the profiles? What type of Group Policy settings could be interfering? Are there any anti-virus clients or security suite packages that slow down the read/writing speed requests when interacting with these shares? What if none of these are concerns & the true problem lies in the machine's connection speed and/or latency to this share? Or what if a combination of these concerns are contributing?  That's all conjecture and not necessarily helpful, I realize, but I make mention of it because the sudden inability to successfully write to your user.config could potentially be something affected by any of those questions (or ones I didn't consider when writing this response).  So something that I think will help, but is dependent on your IT staff.... would they allow you to save your user.config file (that's currently being saved to the default location of your Roaming Profile over the network) to a Local Profile saved on-disk on your machine instead? If the answer is yes, I'd ask that you or your IT staff navigate to the following section of your registry in RegEdit: Computer\HKEY_CURRENT_USER\SOFTWARE\ESRI\ArcGISPro\Settings Once there and at the bottom of the subkey list, you should see the following three subkeys:  An elaboration on what these subkeys are:  For your specific problem, I'd recommend setting UserConfigMovedToRoaming to '0', so that it'll save your user.config in the path specified under UserConfigLocationLocal (which should be on-disk on your machine, ideally) instead of where it's currently being saved under UserConfigLocationRoaming. Making this change isn't going to move any other part of your User Profile locally; it's only changing the save location for your user.config file. As an aside, both UserConfigMovedToRoaming & UserConfigLocationLocal can be modified to point to different locations outside of %APPDATA% & %LOCALAPPDATA%, respectively, if the defaults don't suit your needs for whatever reason. That may be pertinent & helpful if your IT staff is also backing up your Local User Profile (or not using it at all) to a network share.    This concern in general is currently encompassed by the following Enhancement & was implemented because of it:  ENH-000137053 - Allow the Specification of a Local or Roaming Profile Installation Option to Avoid Performance Problems Experienced in some Environments After ArcGIS Pro's user.config File was Migrated from Local to Roaming Storage Although this enhancement is still listed as being Open and/or Under Consideration, it's going to be marked as Implemented in the coming days to point to the solution above that I just described. Regarding documentation for these registry keys, that screenshot I posted above outlining their usage was from an internal page where we're staging these updates - at or before 3.1 Release, they'll be pushed to our public page here to fill the gap: https://github.com/esri/arcgis-pro-sdk/wiki/ArcGIS-Pro-Registry-Keys   Want to reiterate that I don't believe this potential solution for your user customization problems will resolve the performance issues being seen elsewhere in the client - would be pleasantly surprised if they did! You'll need to engage further with Support on those concerns if they continue to persist, but things I'd recommend checking in that regard prior to or during engagement with Support would be: Are Projects that users in your organization are making/working on also being saved directly on the network? Or are they being saved locally on-disk? Does any data those projects contain/reference load that data from network locations, or are they being sourced locally? Does your organization use OneDrive? If so, do any of the above directories from the first two bullet points have backups made regularly during working hours?  Are there any anti-virus or security suite packages that could be combing through any of the above directories where data, projects, etc. are being read & written from?    I'm still subscribed to this post so please don't hesitate to report back with findings when you have them. Finger's crossed this is it!  ... View more

Thank you @JMitchell ; I likely can't give any pointed advice before the weekend juggling my current workload, but by the end of next week at the latest I should be able to discuss something with you. I'll reach back out!  ... View more

@JMitchell - do you happen to have the case numbers you engaged with Support to discuss this issue?  ... View more

Good morning @Suleyman-Arslan - this Idea has been implemented in our latest internal builds of Pro 3.1, and will be included in the formal release once it's ready to be made widely-available. For visibility, the accompanying Support Enhancement number for this idea reads as follows:  ENH-000132235 - Provide a way to un-dock multiple attribute tables at the same time within ArcGIS Pro. As far as how this will look in ArcGIS Pro 3.1, the following 'Float All' context menu option is the implementation of this idea, accessible by right-clicking any of the Attribute Table View tabs in a single dock pane that you'd like to float:      ... View more

Marcel,  We migrated from CefSharp to WebView at Pro 2.9. At 2.9, the following windows use WebView2 to render:  Pop-Ups Charts Infographics tool & Marketing Wizard The Named User Sign-In Dialogue Workflow Manager's Job View The Catalog View's Metadata Display You should be seeing the various (~6) WebView2 windows running when you've interacted with any of the above in a project, and in normal circumstances they should not be interfering with performance, and I can't determine why any of these windows would be specific to annotation editing/cleanup. In the context of your annotation workflow, what does 'cleaning' mean? Are you using an Edit Annotation tool?        ... View more