is it possible to use yours library to create UIautomation based autoit GUi apps?

[JanuszChmiel]

Please, is it possible to use yours library to create Uiautomation based app GUI, so no native Autoit object class names would be used and user would be able to use Uiautomation related object classes? Such as explorer.exe or other UIautomation based GUI apps are using?
If no, how complex would be to extend yours library to support it?
I have also other question to you.
Whx used Edit field is having so fast responsiveness when I AM using NVDA screen reader? And if I use Edit GUi autoit object outside yours uiautomation app, The time between key press and NVDA speaking is slower? Is it because UIautomation libraryes are called? But you are using normal Edit field to display The results.
Or The slowness of other apps is based on The fact, that editable field is waiting to receive data from keyboard and this routine makes Autoit slowdown?

Because before I have analysed yours app and before I have tried it with NVDA screen reader, responsiveness of all not only Edit Autoit GUI elements is slow when comparing with Autohotkey for example.
It would be very nice if we could find The cause. Because in this case, Autoit would be capable to be usable also by visually impaired users more effectively at The same level related to GUI responsiveness with NVDA like Autohotkey is.

[junkew]

The original thread in AutoIt forum https://www.autoitscript.com/forum/topic/153520-iuiautomation-ms-framework-automate-chrome-ff-ie/
This in GitHub fork to be more compatible with AutoIt notation. So its a choice on which syntac you prefer.
AHK is over here https://www.autohotkey.com/boards/viewtopic.php?t=2216
Your questions are to vague for me to understand

The library is fully based on microsoft uiautomationcore.dll so speed is really a matter of giving the right properties to search with.. NVDA an AHK are potentially using the iaccessible interface that recognizes far less objects compared to uia.
This wrapper library or the one in the forum just wraps the dll and can be slow if properties given are not optimal as the search algorithm then tries to search recursively. LarsJ in the AutoIt forum has demonstrated many examples which are all fast in operation.