`RPA.Windows` keyword `Windows Search` is too quick

[kylie-bee]

When using the Windows search keyword, depending on system performance and the status of the search index, Windows may take some time to find the object being searched for, but the sleep is after clicking {enter}. I believe that may be a bug, but in any case, we need to be able to set a sleep between entering the search term and clicking enter.

[cmin764]

These lines are executed to accomplish this:

        self.ctx.send_keys(None, search_cmd)
        self.ctx.send_keys(None, text)
        self.ctx.send_keys(None, "{Enter}")
        time.sleep(wait_time)

so if the pressing of {Enter} happens too fast, we can refactor it into:

        self.ctx.send_keys(keys=search_cmd)
        self.ctx.send_keys(keys=text, interval=0.1, wait_time=wait_time)
        self.ctx.send_keys(keys="{Enter}")
        time.sleep(wait_time if wait_time is not None else self.ctx.wait_time)

if we don't want to raise the complexity with multiple kind of wait_times.

---

As a workaround, would a beforehand Set Wait Time of more seconds solve the issue without any code change required? This will have the following effect:

1. Windows key pressed -> waits previously set wait time
2. Text is typed -> waits previously set wait time
3. Enter is pressed -> waits previously set wait time
4. Waits the passed in wait_time param value (default is 3s)

Then you can revert back to the original global wait time with another call of Set Wait Time to the result returned on the previous call (which is the initial value, default of 0.5s).

The original sleep happening at the end (after pressing Enter) is to wait until the searched app fully opens, as this is what usually takes some noticeable time for the app to finally show and be in a ready state. (so I believe this isn't a bug, but more like a limited way of controlling the sleeps between the actions)

[cmin764]

Additionally, while at this, the RPA.Windows.keywords.action module should suffer the following refactor:

wait_time or self.ctx.wait_time  # bugged when `wait_time` is 0 (aka no wait at all)

to

wait_time if wait_time is not None else self.ctx.wait_time

so I'm going to add back the bug label because of this.

[cmin764]

@blakewaud Go ahead and create a PR if you have some extra time since it sounds like an easy fix. Afterwards you can test it on a Windows machine with a command like inv code.test-robot -r windows -t "Play Task Calculator".

[kylie-bee]

Do we really need a wait after clicking enter? The library has built in timeouts for finding elements, so theoretically, if you called Control window after Windows search, it should have the current global timeout to wait for the app to open... and you could set that before opening the app if you know the app is slow. Otherwise I agree and can look at this next after MSGraph.

[cmin764]

You have a point here and technically this is desirable, but by design our wait_time philosophy here is the amount of seconds to sleep after a command completely finishes and that's totally up to the user if he/she wants to override the default. Also there's no guarantee that somebody will call Control Window (or anything related relying on timeouts) after such Windows Search execution, so maybe somebody just wants to open an app and at the same time set a sleep time long enough for the effect to be observed (before continuing with the rest of the statements), place where sleeping at the end of the command full execution (including Enter) makes sense.

Anyway, how would you improve this patch suggestion to make it even more versatile?

        self.ctx.send_keys(keys=search_cmd)
        self.ctx.send_keys(keys=text, interval=0.1, wait_time=wait_time)  # this is what solves the issue
        self.ctx.send_keys(keys="{Enter}")
        time.sleep(wait_time if wait_time is not None else self.ctx.wait_time)  # since we will allow default context time waits here as well (more flexibility)

Of course, the downside is that there are two identical sleeps now: one between finishing typing & pressing Enter and another at the end of the command chain.