Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data captured by pywinauto with delay #1366

Open
froxplus opened this issue Jan 5, 2024 · 2 comments
Open

Data captured by pywinauto with delay #1366

froxplus opened this issue Jan 5, 2024 · 2 comments
Labels

Comments

@froxplus
Copy link

froxplus commented Jan 5, 2024

I am automating a WPF application. it uses external data sources to show data as tables.
data has a hierarchy and based on data type they are shown in multiple tables
in my case, there is a data type that has a table as root and two other tables as siblings divided into tab items
when I select a row in the main table based on the data of the row there are 0-10 rows in each sibling table
I read the main table data at first using the following code and then click on each row of it and try to read sibling tables
the main table read fine
but when I try to read sibling data there is a delay between the data shown on UI and data gathered by pywinauto
I'd added sleep after each row click but it is not constant and there are some times that pywinauto captures previous data from sibling tables (if I increase sleep it would be corrected)
some points:

  • data is on the application's memory and there is no actual delay between row click and data presented on table
  • there is no relation between the size of the data and the delay
  • if I increase sleeps between row click and data read it would solve the problem but it will not pass my tests
  • same behavior on multiple machines with various hardware configurations (aka intel 12700K)

Expected Behavior

read correct and updated data from the UI

Actual Behavior

there are random delays between the time data shown on UI and the same data can be captured using pywinauto

Steps to Reproduce the Problem

  1. open the page with multiple tables, data of sibling tables are related to selected row on main table
  2. iterate over rows of main table
  3. read data from sibling tables

Short Example of Code to Demonstrate the Problem

def get_data_grid(gridview, iterate_rows=False) -> tuple[list, list]:
    data = []
    headers = {}
    rows = []
    try:
        time.sleep(0.75)
        data_rows = gridview.descendants(control_type="DataItem")
        if len(data_rows):
            headers = gridview.descendants(control_type="HeaderItem")
            for index, header in enumerate(headers):
                properties = header.legacy_properties()
                headers[index] = properties["Name"]

            for data_row in data_rows:
                info = {}
                for element in data_row.children():
                    legacy_properties = element.legacy_properties()
                    info[headers[int(legacy_properties["Name"].split(" ")[-1])]] = legacy_properties["Value"]
                if iterate_rows:
                    rows.append({"element": data_row})
                data.append(info)
    except Exception as ex:
        logging.error(ex)
    return data, rows

Specifications

  • Pywinauto version: 0.6.8
  • Python version and bitness: 3.10 64bit
  • Platform and OS: Windows 10 Pro 22H2 19045.3803
@vasily-v-ryabov
Copy link
Contributor

Even if the data is in memory of the application, it must be copied to the UI table memory to be displayed. Copying also takes non-zero time and most probably it is CPU bound a little bit (memory transaction makes one CPU core waiting). I'd suggest to try calling app.wait_cpu_usage_lower(...) and to tune its params to achieve balance between reliability and speed.

@vasily-v-ryabov
Copy link
Contributor

All the methods to work with waits are here: https://pywinauto.readthedocs.io/en/latest/wait_long_operations.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants