Check App State does not work as expected

Help Activities
, , ,
1

I am using Check App State for if a window of a legacy application opens.

Irrespective of the element appears or not it goes to the Target Appears flow. It never goes to the Target Does not Appear flow.

I have checked the selector, its a simple selector and works fine.

Is it an issue with the modern activity?

2

Hi @kkpatel

What is the selector you have given in CheckApp State and the application which you are opening. Can you share the screenshot.

Regards
Parvathy

3

sorry I can not share that. but the issue is simple as I have described.

and I see same issue reported here in forum by other users.

4

Hi @kkpatel,

Check below points and see if you are missing any of these.

  • Check App State by default waits up to its Timeout value before deciding “not appeared.” If your element appears intermittently within that window, it’ll route to “Target Appears” even when you expect it not to. Check the Timeout property carefully.
  • You said it’s simple and “works fine”, but “works fine” usually means it matched something (Selector may be too loose / matches something else on screen). For legacy apps (Win32), a loose selector (e.g., missing “title” or using wildcard idx) can match a different but structurally similar control that’s always present, so it always evaluates as present. Open UI Explorer, validate the selector correctly.
  • If Check App State’s scope is set too broadly (Wrong scope for “Work in scope”), it may find a similar control elsewhere in the OS and treat it as a match even when the actual target app window is closed.
  • Confirm you’ve set the right condition, “Exists” checks presence only; if you’re checking “Enabled” or “Visible” as the AppState instead of “Exists,” a hidden-but-existing element can still trigger “Target Appears.”

I hope this helps.

Cheers!

5

This is the key.

I want to understand it better. this is happening. For one transaction it appears, and for the next transaction item it may not appear. in that case it should go to Target does not Appear.

But its still going to to Target Appears, which is wrong and if this is how it works then its a flaw from UiPath side right ?

6

Yes, it can be an issue with the Modern Check App State activity, especially with legacy applications.

Try:

  • Test the same selector with Classic Element Exists.
  • If Classic works correctly, use it instead.
  • Also verify that the selector isn’t matching an element that remains in the UI tree even when the window is hidden.
7

Hi @kkpatel,

If an element appears even briefly, or a similar element matches, it’ll route to “Target Appears” even when you expect it not to. Check the Timeout property, try lowering it to something like 3-5 sec for a real test, and see if behavior changes.
Try using Wait Active property in Check App State activity, this will check if the Elements top level windows is on foreground.

It may not be a flaw, since I do not see any issues with it as I am using it across different processes. Check and update/downgrade the UiPath.UIAutomation.Activities package, sometimes it could be the reason why it fails on Check App State activity.

Also, as an alternative you can try Get Text (include Retry Scope surrounding Get Text activity) and put an If condition to check if the text is present once a new page is opened.

Also, as an alternative you can try using Classic Element Exists activity for now, but I do not recommend using it, because classic activities maybe deprecated anytime in future.

Cheers!

8

I have tried all, and it doesn’t work the correct way. and I do not see any Wait Active property in Check App State activity.

9

Hi @kkpatel ,

I think everyone here is looking at the wrong thing. Your selector is probably fine.

Modern Check App State doesn’t only use the strict selector. Fuzzy Selector and Computer Vision run alongside it, and whichever finds something first wins. So even when your window is gone, fuzzy/CV matches something similar still on screen and it goes to Target Appears. That’s why it never hits the other branch.

Try this:

Open the target, uncheck Fuzzy Selector, Computer Vision and Image. Keep Strict Selector only. Also set Visibility check to Fully visible, and drop Timeout to 3 sec for testing.

One thing worth checking first - open the target editor and see if the Strict Selector box is actually empty. That happens a lot when you indicate a whole window instead of a control inside it. If it’s empty, that alone explains everything.

Quick test: close the window, keep the app running, then hit Validate on that strict selector in UI Explorer. If it still goes green, you’re matching a leftover hidden window and you need visible=‘1’ in the selector.

10

Hi @kkpatel

Can you try below

  1. In CheckAppState activity use Strict selector - if you are using aaname attribute try with visibleinnertext attribute
  2. CheckAppState activity properties - Visibility check property use Fully visible

image
image347×738 76.5 KB

Regards,

11

Yes, this is what I can see. But what does it explain?

12

@kkpatel ,

Empty Strict Selector means the activity has no exact rule to match on. So only Fuzzy Selector and Computer Vision are actually running, and both of those work on “closest match” - they always find something. That’s why you never reach Target Does Not Appear. There’s nothing that can return false.

Two ways to fix it:

  1. Re-indicate, but pick a control inside the window (a label, a button, a text field), not the window frame itself. You’ll get a proper strict selector.

  2. Or just type it in yourself. In the target editor, paste into the Strict Selector box:

Get the real app/cls/title values from UI Explorer while the window is open.

Then uncheck Fuzzy Selector and Computer Vision so only Strict runs, and set Visibility check to Fully visible.

After that close the window and hit Validate on the selector. It should go red. If it goes red, your Target Does Not Appear branch will start working.

13

Hi @kkpatel just adding a small thing to what Subharjun explained

if you go with his fix, id do it in that order, first re indicate a control inside the window so you actually get a strict selector, and only then uncheck Fuzzy and Computer Vision. If you uncheck them while the strict box is still empty, the activity ends up with nothing to match on and i think it will just fail validation, wich might look like the suggestion didnt work

also worth lowering the Timeout while testing, otherwise every false case takes the full wait and it gets painfull to debug

hope this helps as well :slight_smile:

14

tried everything. no change. Its still waiting for the element to appear for ever even if I have given timeout as just 3 secs.

and eventually its going to Target Appears. It never goes to Target Does not Appear.

15

@kkpatel ,

The “waits forever even with 3 sec” bit is the real clue. That timeout isn’t the one being used. Check the Use Application/Browser scope, it has its own Timeout, and Project Settings > UI Automation Modern > Timeout which defaults to 30. Set those to 3 too.

For the branch itself, quickest way to know who’s at fault: drop a classic Element Exists on the same selector, timeout 3000, output to a bool, log it. Close the window and run.

If it logs True with the window closed, your selector is catching a hidden leftover window. Add visible=‘1’ to it.

If it logs False, selector is fine and Check App State is the problem on your version. Just use Element Exists + If and move on.

16

@kkpatel

  1. Can you paste only the selector here.or tell what you have e in the strict selector may be only the attributes like app,class,id etc
  2. If the strict selector is emoty or not having what much attributes it can think other windows also are similar and detect
  3. Also as others said fuzzy and all need to he unchecked
  4. If the window is appearing while the avtivity starts and if it disappears after a few milliseconds as well it would detect the window to be present

Explaining your scenario completely with these details would help to solve the issue

Cheers