TLDR dude: I need to obtain all window titles regardless of whether they are active, minimized, hidden, in another dimension, whatever. If there are multiple instances of windows with the same title I want the workflow to either terminate or force the user select the window they want the bot to attach to. Just looking for something simple that works inside an “invoke code” activity (or other option) that can capture ALL window titles. That’s it. Because I know this will be asked: No I cannot have the bot just open a new instance of this window and attach to it to perform x, y, z. No, I can’t kill all processes in question and open a new instance and perform a, b, c. If you know how to do this, read no further.
I’ve finished building a bot that automates an application with semi-exposed Chromium containers. The way the bot works is a user opens one of these windows then runs the bot which utilizes the “attach window” activity.
There can multiple instances of these windows open with the same selectors (app and cls) but it’s the “title” that helps the bot distinguish between them. However, I can already foresee cases where users will have multiple windows open where the “title” is the same too.
It’s my wishful assumption that when confronted with windows with identical selectors UIPath uses the last active instance, which would probably be fine in most scenarios. Problem is, I’d rather not have the bot operate off this assumption. And any additional selectors beyond app, cls and title are irrelevant.
I’ve tried using the “System.Diagnostics.Process inside a for each process in processes loop activity” shtick. While this does return all running process names and some window titles… It doesn’t do so for the type of window in question unless it’s in the foreground and/or activated.
I figured the next best option would be to use the “invoke code” or “invoke powershell” activity. There are some vba/powershell examples I have found that accomplish what I need like:
But there’s got to be a way to accomplish this without invoking a wall of code or venturing down the “escape quote” rabbit hole of invoking the powershell script, no?