Accessibility issue with the large sleep in AutoIt GUI message loop

[darking]

Hi guys!

I've just signed up here and I hope I'm not posting this topic in the wrong forum and such.

I am a blind programmer who'd like to use an automation tool to simplify some things for myself or implement accessibility for some things that are not accessible by no other means (like mouse click in a certain place).

Well, I've tried both AutoIt and AutoHotKey in the last few days and I can certainly say that whoever has a programming background like me would be repulsed by AHK syntax!

Beside that, I looked at the function reference and it covers my needs way better than AHK.

And let's not forget the UDFs.

I only have an issue with the AutoIt's implementation of GUI that I didn't have this problem with AHK when I tested it:
I'm not sure my guess is correct or not but I guess AutoIt uses a large sleep time in its GUI message loop.
This might not be an issue for the sighted users but for someone who uses screen readers they have major performance issue with the GUI.
To be mor specific: An AutoIt GUI lags the screenreader when we're trying to navigating using the"TAB" key because the screenreader needs to get its information from the windo.
While AHK GUIs ran smoothly.
I'd really like to continue using AutoIt but this is a major problem for me.
Is there anyway it could be fixed?
Or, Is there any beta version (or alternative version) that doesn't have this problem?
Or, Is there any hope of this being fixed in the near future?

Looking forward to your replys!

[Jos]

Don't put any sleep() statements in a GUI message loop or use "GUI OnEvent Mode" (see helpfile for details.

Jos 

[darking]

That was also my point: I meant the AutoIt implementation of GUI. Not the scripts.

And, I've used both mode with no luck.

I've asked someone else about this and he answered that There's nothing much that I can do because AutoIt developers have a really large sleep time in the windows message loop of the window and it's fine for sighted people but screen readers lag as a result.

That's why I asked this here to see if there's anything I can do to fix such an issue or if it is going to be fixed?

Thanks!

[Jos]

14 minutes ago, darking said:

because AutoIt developers have a really large sleep time in the windows message loop

There is a 10 msec pause when GUIGetMsg() is done just to ensure not using too much CPU. Other than that I wouldn't know what is meant here.

Jos

[Simpel]

Hi.

can you recommend a screen reader that is for free and even portable to test with?

Conrad

[darking]

Yeah, I myself am using NVDA which is free, portable and open source.

You can visit its website at https://www.nvaccess.org/ and download it.

[mLipok]

Show the main message loop with entire Select Case structure.
You can delete all contents beetwen Cases 

I remember that long time ago, I had a some issue with this, and of course it was my fault.

To show you what I mean from example

Local $idMsg = 0
    ; In this message loop we use variables to keep track of changes to the radios, another
    ; way would be to use GUICtrlRead() at the end to read in the state of each control
    While 1
        $idMsg = GUIGetMsg()
        Select
            Case $idMsg = $GUI_EVENT_CLOSE
                MsgBox($MB_SYSTEMMODAL, "", "Dialog was closed")
                ExitLoop
            Case $idMsg = $GUI_EVENT_MINIMIZE
                MsgBox($MB_SYSTEMMODAL, "", "Dialog minimized", 2)
            Case $idMsg = $GUI_EVENT_MAXIMIZE
                MsgBox($MB_SYSTEMMODAL, "", "Dialog restored", 2)

            Case $idMsg = $idButton_1
                MsgBox($MB_SYSTEMMODAL, "", "Default button clicked:" & @CRLF & "Radio " & $iRadioVal1)

            Case $idMsg >= $idRadio_1 And $idMsg <= $idRadio_3
                $iRadioVal1 = $idMsg - $idRadio_1

        EndSelect
    WEnd

and here you have what I'm asking for:
 

Local $idMsg = 0
    While 1
        $idMsg = GUIGetMsg()
        Select
            Case $idMsg = $GUI_EVENT_CLOSE
                .....
            Case $idMsg = $GUI_EVENT_MINIMIZE
                .....
            Case $idMsg = $GUI_EVENT_MAXIMIZE
                .....
            Case $idMsg = $idButton_1
                .....
            Case $idMsg >= $idRadio_1 And $idMsg <= $idRadio_3
                .....
        EndSelect
    WEnd

 

[darking]

Well I've written two sample GUIs with the two modes available in AutoIt and they both have lag issue at least with NVDA that I'm using:

 

The first one using the message loop...

 

#include <GUIConstantsEx.au3>

Main()

Func Main()
    Opt("GUICoordMode", 2)
    GUICreate("Example GUI", 400, 400)
    GUISetCoord(10, 10)
    $note = GUICtrlCreateLabel("This is a label for testing purposes...", -1, 10, 380, 330)
    $en = GUICtrlCreateButton("OK", -1, 10, 175, 30)
    $dis = GUICtrlCreateButton("Cancel", 20, -1, 175, 30)
    GUISetState(@SW_SHOW)

    While 1
        Switch GUIGetMsg()
            Case $en
                MsgBox(0, "MsgBox", "You pressed OK...")
            Case $dis
                Exit
            Case $GUI_EVENT_CLOSE
                ExitLoop
        EndSwitch
    WEnd
    GUIDelete()
EndFunc   ;==>Main

 

 

And the second one using the OnEvent mode...

 

#include <GUIConstantsEx.au3>
#include <MsgBoxConstants.au3>

Opt("GUIOnEventMode", 1) ; Change to OnEvent mode

Local $hMainGUI = GUICreate("Hello World", 200, 100)
GUISetOnEvent($GUI_EVENT_CLOSE, "CLOSEButton")
GUICtrlCreateLabel("Hello world! How are you?", 30, 10)
Local $iOKButton = GUICtrlCreateButton("OK", 50, 50, 40)
GUICtrlSetOnEvent($iOKButton, "OKButton")
Local $iCancelButton = GUICtrlCreateButton("Cancel", 100, 50, 80)
GUICtrlSetOnEvent($iCancelButton, "CLOSEButton")
GUISetState(@SW_SHOW, $hMainGUI)

While 1
    Sleep(10) ; Sleep to reduce CPU usage
WEnd

Func OKButton()
    ; Note: At this point @GUI_CtrlId would equal $iOKButton,
    ; and @GUI_WinHandle would equal $hMainGUI
    MsgBox($MB_OK, "GUI Event", "You selected OK!")
EndFunc   ;==>OKButton

Func CLOSEButton()
    ; Note: At this point @GUI_CtrlId would equal $GUI_EVENT_CLOSE,
    ; and @GUI_WinHandle would equal $hMainGUI
    MsgBox($MB_OK, "GUI Event", "You selected CLOSE! Exiting...")
    Exit
EndFunc   ;==>CLOSEButton

 

Edited March 23, 2018 by Jos
formatted code

[Jos]

What kind of lag do you experience on your computer with each version?
in other words, what do you do to experience the lag?

Jos

[Jos]

I have changed the second script to the below and can keep on clicking the Ok button just fine:

 

#include <GUIConstantsEx.au3>
#include <MsgBoxConstants.au3>

Opt("GUIOnEventMode", 1) ; Change to OnEvent mode

Local $hMainGUI = GUICreate("Hello World", 200, 100)
GUISetOnEvent($GUI_EVENT_CLOSE, "CLOSEButton")
GUICtrlCreateLabel("Hello world! How are you?", 30, 10)
Local $iOKButton = GUICtrlCreateButton("OK", 50, 50, 40)
GUICtrlSetOnEvent($iOKButton, "OKButton")
Local $iCancelButton = GUICtrlCreateButton("Cancel", 100, 50, 80)
GUICtrlSetOnEvent($iCancelButton, "CLOSEButton")
GUISetState(@SW_SHOW, $hMainGUI)

While 1
    Sleep(10) ; Sleep to reduce CPU usage
WEnd

Func OKButton()
    ; Note: At this point @GUI_CtrlId would equal $iOKButton,
    ; and @GUI_WinHandle would equal $hMainGUI
    ConsoleWrite("GUI Event...You selected OK!" & @CRLF)
EndFunc   ;==>OKButton

Func CLOSEButton()
    ; Note: At this point @GUI_CtrlId would equal $GUI_EVENT_CLOSE,
    ; and @GUI_WinHandle would equal $hMainGUI
    ConsoleWrite("GUI Event...You selected OK!" & @CRLF)
    Exit
EndFunc   ;==>CLOSEButton

... the same counts for the first example when changing the msgbox to consolewrite... no lag what so ever.

Jos

Edited March 23, 2018 by Jos

[Bilgus]

I did NOT notice any lag when using the tab key to move between controls on the sample forms you provided.

This is using nvda_uiAccess.exe with my processor limited to 800 mhz. Is there anything special I am missing in your use case?

[Simpel]

I tested both examples and I didn't face any lags too. I used the standard preferences. I just started the nvda as a portable version and it worked very quick.

Regards, Conrad

[mLipok]

2 hours ago, darking said:

Well I've written two sample GUIs with the two modes available in AutoIt and they both have lag issue at least with NVDA that I'm using:

Does this two examples works well without NVDA , on yours 800 Mhz processor ?
 

[darking]

Thanks guys for testing and replying...

 

Well, it's not a big lag but if you put a few controls on the GUI (like buttons and textboxes), when you try to press "tab" key to quickly cycle through them it's noticible...

 

for instance, try to press tab key quickly both in an autoIt GUI and something else like windows explorer...

[Earthshine]

it may just be a case of how your machine is configured. no? I wish there was an online machine compare we could look at config differences and stuff

[Jos]

I can imagine that the software you are running can introduce this behavior as that has to do screen scraping each time the gui updates.
Not if that is something that we can change and how easy it is to test.

Jos

 

[Bilgus]

@darking what happens if you raise the priority of the au3 script does it lag less?

#include <AutoItConstants.au3>
ProcessSetPriority(@AutoItPID, $PROCESS_HIGH)

 

[Fenzik]

Hello all,

I'm using Autoit and NVDA together too.

Slow performance of Autoit Gui is visible also in Text fields (Edit, Richedit. When you have longer text field, performance of NVDA during reading line by line is slower than in other programs, regardless on Loop or event mode.

Friend of mine noticed, that in Autoit v3.2.10.0 was gui as fast as in other programs.

So you can compare gui performance with Nvda in those two versions of Autoit and check which change makes this actual interaction behaviour.

 

[Earthshine]

slow performance on what hardware and what os, how much memory and resources are we actually talking? maybe you need a new computer.

[Fenzik]

It's not dependent on hardware.

Slow performance of Autoit gui with screen readers is the same regardless on running PC.

Best way to notice it is comparation with other programs.

For example edit in Notepad is more faster operable than edit created in Autoit Gui.