Several months ago I was attempting to find a solution for random pop-ups. -- The kind that could appear at almost any point during a workflow and would completely break the workflow if not handled immediately. These type of pop-ups can be very difficult to predict and/or may appear at many, many places in a workflow. Creating a pop-up "checker" and "closer" at each of these potential-pop-up locations was simply not feasible.
In researching a solution, I noticed that there were many, many posts complaining about pop-ups online, but at the time there were no good solutions on the forum. I created this framework to address that deficiency.
What it does
The Pop-Up Handler constantly checks for and closes any number of pop-ups as the user's primary process is running. The user can choose both (A) which pop-ups the handler should be looking for, and (B) how it will handle those pop-ups.
The Pop-Up Handler can also be used as a user-assisted automation if certain pop-ups should be closed automatically without the user being allowed to choose (or mis-choose) which option to press.
The Pop-Up Handler is created using very basic UIPath activities. (A Parallel statement is the most complicated part of this automation.) Since Pop-Ups are such a pervasive issue and are something that many new users are likely to encounter very early on while using UIPath, I wanted to make this framework extremely easy to use and modify, even for the newest members of the UIPath community.
See included "Instructions" document for full details.
How I built it
The Pop-Up Handler consists of a Parallel statement containing (A) the user's primary workflow, and (B) any number of pop-up "catches", each of which the user can program to handle one (or multiple similar) pop-ups. Each pop-up "catch" is a short flowchart consisting of an "Element Exists" activity followed by "If so, then... Click Button" logic, in a tight infinite loop.
To modify the pop-ups being handled, the user need simply select a new target for (A) the "Element Exists" activity (this should be the body, or a defining element of the pop-up to be handled), and (B) the "Click" activity (this should be the button to be clicked) within one of these pop-up "catch" flowcharts.
The Pop-Up Handler works well in most situations, but does have a few important limitations: (1) If a pop-up occurs while an activity within the primary workflow is being executed, the pop-up will not be handled until after that activity has finished running. E.g. if a pop-up appears in the middle of a Type Into activity, the pop-up handler will not kick in until AFTER the Type Into has either completed or thrown an error. For "long" activities during which this could be a problem, Try Catches surrounding the activity involved can potentially be used to help mitigate this behavior. (2) If a pop-up occurs within a scope (e.g. an Excel or browser scope) inside the user's primary workflow, the pop-up handler still may not be able to handle it. (Note that limitation (2) is essentially just a special case of limitation (1).) (3) Many pop-ups will pull the "focus" away from whatever UI element is being interacted with when they appear. The Pop-Up Handler cannot prevent this change in focus. As a result, the user should use re-focusing settings (e.g. "Activate" or "ClickBeforeTyping") or use activities that do not require focus (e.g. "SimulateClick" or "SendWindowMessage") as much as possible during portions of the primary workflow where pop-ups are anticipated.