Version 2 of some Accessibility code.

[neogna2]

I suggest posting code and details about a specific issue in the Ask for Help v2 forum, showing the non-working code and working v1 code.

My post earlier in this thread has a short v1 and v2 script that reproduce the issue with v2 Acc_Children() throwing error.

The scripts can be used with Acc v2 version by eugenesv's 2022-02-22 (latest) from viewtopic.php?p=433516#p433516
and Acc v1 from https://github.com/Ixiko/AHK-libs-and-classes-collection/blob/master/libs/a-f/ACC.ahk

I could copy and paste all this to "Autohotkey v2 Help" section. But as this thread already covers discussion/troubleshooting for the two v2 Acc work in progress library attempts isn't it better to continue that discussion here?

edit:
I tried to track down different Acc v1 versions, and ended up with this list
2010-02-25 https://github.com/Drugoy/Autohotkey-scripts-.ahk/blob/master/Libraries/Acc.ahk
2012-02-19 https://github.com/Ixiko/AHK-libs-and-classes-collection/blob/master/libs/a-f/ACC.ahk
2012-10-25 https://github.com/evilC/Spreadsheet-Barcode-Scanner/blob/master/scanner.ahk#L525 (embedded in larger script)

There's also
2019-05-10 https://github.com/sancarn/ACC.AHK (forum thread). But note that author sancarn says "incompatible with old Acc.ahk scripts"

This @just me 2017 code may also be relevent to v2 Acc efforts
viewtopic.php?t=40532#p189883

[lexikos]

I could copy and paste all this to "Autohotkey v2 Help" section. But as this thread already covers discussion/troubleshooting for the two v2 Acc work in progress library attempts isn't it better to continue that discussion here?

And how has it worked out for you so far? Why do you think I made the suggestion?

A topic in Ask For Help would give the problem more exposure to users who aren't specifically interested in Acc, or aren't expecting to find a request for help buried in a topic in the Scripts forum.

A self-contained topic focused on one issue, with the problem being clearly identified, may help whoever might be able to help you solve the problem, especially those who aren't interested enough to parse through this topic.

[neogna2]

Ok. I now made the post "v2 Acc.ahk library Acc_Children() error" in the v2 Help section.
viewtopic.php?f=82&t=107471

[lexikos]

(This should not have any impact on the issue described above.)

Code: Select all

childX	:= NumGet(vChildren, i-8, "Int64") ; vt ?

As shown in the comments, VARIANT::vt is not Int64; it is a 16-bit integer followed by 3 reserved 16-bit fields. In this case, it is unlikely to make any difference, but I would change "Int64" to "UShort" anyway.

Code: Select all

if (gotChildren = 0) {

In general, the correct way to check a HRESULT value (interpreted as a signed 32-bit integer) for success is if (gotChildren >= 0). For instance, it allows the following case described by the documentation:

S_FALSE
The function succeeded, but there are fewer elements in the rgvarChildren array than there are children requested in cChildren.

If you instead change the DllCall return type to "hresult", you generally do not need to check the return value, as DllCall will throw an OSError on failure. You can still use the return value to check for the condition described above, if needed.

Code: Select all

    if (cChildren=0) {
      return 0
    }

I assume this came from the v1 code. In v1, Loop a.Length() and for i, item in a would have no iterations whether a was an empty array or the number 0. In v2, attempting to treat 0 as an array will produce an error. I think it would be more appropriate to return [] when there are no children, so it is no longer a special case, although that would change the result of any checks for "truth" of the return value (if children).

Code: Select all

Acc_Init(){
  static h	:= 0
  If Not h {
    h := DllCall("LoadLibrary", "Str","oleacc", "Ptr")
  }
}

It would be more efficient to write static h := DllCall("LoadLibrary", "Str","oleacc", "Ptr"). In v2, the static initializer is evaluated only when the function is called, and actually removes itself from the function upon success.

If you're not aiming to keep the library as close to the v1 version as possible, you could eliminate Acc_Init() altogether, replacing it with #DllLoad oleacc (specified once, anywhere in Acc.ahk). This would allow each DllCall to be optimized automatically, but would have the effect of loading oleacc.dll immediately when the script starts, instead of only when an Acc function is used for the first time.

Code: Select all

VarSetStrCapacity(&sRole, 2*nSize)

VarSetStrCapacity deals in characters, not bytes, so 2* is unnecessary.

[Descolada]

My attempt at Acc v2

Run Acc.ahk to display AccViewer, or include in your script to use the library.

Syntax has been changed greatly when compared to v1. For example:

Code: Select all

WinGet,hWnd,id, File Explorer
oAcc := Acc_Get("Object", "4.5.4.1.4.9.4.1.4.1.4.1.4.1", 0, "ahk_id " hWnd) ; selects the Search Quick Access edit field
MsgBox % Acc_Role(oAcc) "; " Acc_State(oAcc)

becomes

Code: Select all

MsgBox(Acc.ObjectFromWindow("File Explorer")[4,5,4,1,4,9,4,1,4,1,4,1,4,1].RoleText)

The "path" should still be the same though, just needs to be used as an array and periods replaced by commas.

Still has some work to do though. For example I think the performance of Acc.IAccessible.__Get and __Set could be improved greatly...

[neogna2]

If you're not aiming to keep the library as close to the v1 version as possible, you could eliminate Acc_Init() altogether, replacing it with #DllLoad oleacc (specified once, anywhere in Acc.ahk). This would allow each DllCall to be optimized automatically, but would have the effect of loading oleacc.dll immediately when the script starts, instead of only when an Acc function is used for the first time.

A general question: Are there any drawbacks/costs with loading oleacc.dll on script start (and keeping it running for a longer time) compared to waiting until right before some Acc action is needed? And, related, are the any drawbacks or likely problems if two or more (perhaps dozens) of separate scripts load and use Acc concurrently?

[lexikos]

Not that I am aware of.