On 3/5/21 10:44 AM, Marco Zehe via lazarus wrote:
Hi David!
Wow, that sounds exciting! Look forward to your patch.
I did some digging, and found that on Windows, TTreeView does not create any
handles at all yet. It would require at least some basics there, or even
accessibility properties, but I am still hoping we can avoid what I had to do
for TVirtualStringTree in 2007, implementing literally two IAccessible
interfaces, one for tree, one for the focused tree item. That all was managed
by a singleton class instance, and juggled quite a bit. Pretty unreliable, so I
hope we can make it better in TTreeView for the LCL.
Right now, however, I don’t even know where to start yet to implement this.
There is a unit in the Win32 folder, but nothing in there besides the comments.
And from what it sounds like, it makes sense to wait for your patch so I, or
we, can then build on that and make the Windows implementations better.
Marco
For any tree type objects that I have dealt with (both LCL and custom) I
have created Ax objects for the tree and Ax objects for the items as
well. And in cocoa I had to create an additional layer: Tree/Row/Item
in Row.
A couple of deficiencies that I have run across with the LCL
accessibility layer are
1) No notification capability
both Cocoa and Qt include functionality to send notifications to Ax
Clients to let them know of changes to the UI
2) TLazAccessibleObject handle creation doesn't sync well with
TLazAccessibleObject.Ownercontrol handle creation.
Both Cocoa and Qt include accessibilty support in their base widgets
that can be leveraged as TlazAccessibileObject handles. But
TLazAccessibleObject will request a handle before the associated
TWinControl has handleallocated and doesn't know to retry for a handle
after the TWinControl get's its handle.
It would be good to include a path where TLazAccessibleObject handle is
requested after the TWinControl.Handle is created.
I will note that reading the comments surrounding the
TLazAccessibleObject code in Controls and control.inc are important. I
made a couple of bad assumptions about how the code worked before I read
all the comments.
The first was that TLazAccessibleObject.Children objects are not meant
for TControl or TWinControl objects. They are only for visual items
that don't have a TControl or TWinControl object. E.g. row items in a
tree view.
And the difference in getting children by either using the iterator or
doing First / Next. The iterator returns the objects in the child tree
only. First / Next will get the objects from the child tree but also
any TControls that are in the ownercontrol.Controls() array. The latter
allows code to find ALL the children - visual only and TControl objects.
--
_______________________________________________
lazarus mailing list
[email protected]
https://lists.lazarus-ide.org/listinfo/lazarus
