Change in label text doesn't trigger rehint and relayout

Describe the bug Using yield in a function that gets triggered from an buttons on_press event is not responding on Windows.

To Reproduce Steps to reproduce the behavior:

1. Click Button
2. See No Change

Expected behavior The label should show “RUN1” and after 5s change to “RUN2”

Screenshots If applicable, add screenshots to help explain your problem.

Environment:

• Operating System: Linux
• Python version: 3.9
• Software versions:
  • Briefcase: 0.3.3
  • Toga: 0.3.0.dev25 Additional context The Installer is build with the following file:

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions

name: Windows

on:
  push:
    branches: [ master, workflow-test, app-path, windows-yield ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: windows-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python 3.8
      uses: actions/setup-python@v2
      with:
        python-version: 3.8
    - name: Install dependencies
      run: |
        #apt-get update
        #sudo apt-get install git python3-dev python3-pip libgirepository1.0-dev libcairo2-dev libpango1.0-dev libwebkitgtk-3.0-0 gir1.2-webkit-3.0
    - name: Beeware dependencies
      run: |
        # stop the build if there are Python syntax errors or undefined names
        python -m pip install beeware
        python -m pip install dhooks
    - name: Run tests with pytest
      run: |
        cd src/
        python -m unittest test_app.Test_Profile_Manager.test_swap_xml -v
        python -m unittest test_app.Test_Profile_Manager.test_delete_profile -v
        python -m unittest test_app.Test_Profile_Manager.test_create_profile -v
        python -m unittest test_app.Test_Profile_Manager.test_load_profile -v
        python -m unittest test_app.Test_Profile_Manager.test_get_ethnic -v
        python -m unittest test_app.Test_Profile_Manager.test_switching_profiles_with_invalid_path -v
        python -m unittest test_app.Test_Profile_Manager.test_migrate_function -v
        python -m unittest test_app.Test_XML_Parser -v
        python -m unittest test_app.Test_RTF_Parser -v
        python -m unittest test_app.Test_Config_Manager -v
        python -m unittest test_app.Test_Xml_Writing -v
        python -m unittest test_mapper.Test_Mapper_Generate_Mapping -v
        python -m unittest test_mapper.Test_Mapper_Preserve_Mapping -v
        python -m unittest test_mapper.Test_Mapper_Overwrite_Mapping -v
    - name: Build
      run: |
        briefcase create
        briefcase build
        briefcase package
    - name: Save Installer
      uses: actions/upload-artifact@v1
      with:
        name: NewGAN-Manager-Installer-Win
        path: windows\NewGAN Manager-1.1.0.msi

The app.py

"""
Yield Test
"""
import toga
import time


class NewGANManager(toga.App):

    def startup(self):
        self.main_window = toga.MainWindow(self.name)
        self.output = toga.Label("")
        self.btn = toga.Button(label="Run", on_press=self.calc)
        self.main_box = toga.Box()
        self.main_box.add(self.output)
        self.main_box.add(self.btn)
        self.main_window.content = self.main_box
        self.main_window.show()
    def calc(self, widget):
        self.output.text = "RUN1"
        yield 0.1
        time.sleep(3)
        self.output.text = "RUN2"
        yield 0.1

def main():
    return NewGANManager('Toga Demo', 'org.beeware.toga-demo')

more info here: https://github.com/Maradonna90/NewGAN-Manager/tree/windows-yield

[saroad2]

Hey @Maradonna90 , Actually, I have absolutly no idea, but I will try to give it a look over the weekend 😃

Ping me again if for some reason I forget .

[freakboy3742]

@Maradonna90 Hrm… maybe. There’s a lot of similarity with what we’re doing right now - posting Actions into the main loop. However, I’m unclear if the piece with the getting the CurrentDispatcher will work around the problems that exist with starting the asyncio event loop in a separate thread. It’s definitely worth an experiment.

As for “this has nothing to do with Python.net”: you submitted a bug report that referenced some random, incomplete code from a different project; so they closed the ticket as being unrelated to Python.net. From their perspective, that was the 100% right call. That doesn’t mean there isn’t a problem with Python.net - it means you didn’t ask a question that gave them any ability to respond. It’s up to us to narrow down a specific use case that highlights a problem with Python.net’s object disposal policy.