This looks like broken algorithm since table is not supposed to
implement IAccessibleText interface but the caret can be placed inside
of table cells (what provide IAccessibleText interface) and in this
case it doesn't allow you to find real caret offset. My suggestion
would be (as in mozilla bug
https://bugzilla.mozilla.org/show_bug.cgi?id=573719) request IA2
change like
interface IAccessibleText {
[propget] HRESULT accessibleWithCaret (
[out, retval] IUnknown **accessible);
};
what returns deepest text accessible containing the caret if the caret
in the subtree of the object the method is called on.
Thank you.
Alex.
On Mon, Jul 5, 2010 at 8:57 AM, Arnstein <[email protected]> wrote:
> From the implementatin guide:
>
> "The Caret"
> 2.start from the object with focus, and by recursively using the
> IAccessibleHypertext interface, find the object that contains the caret,
> and ...
>
> I interpret this as you may find the object that contains the caret by
> only using the IAccessibleHypertext interface.
> It seems impossible to achieve this, since an object associated with an
> embed character may be a table. From there you need to use "1. Start
> from the object with focus, and by recursively using the
> AccessibleChildren function provided by MSAA, find the object that
> contains the caret;", only that you start from the table. Am I wrong, or
> can it be done in another way? The guide is unclear here.
>
> Using a combination of IAccessibleHypertext and AccessibleChildren is
> still quite a lot faster than only using on AccessibleChildren,
> depending on the internet page.
>
> - RaZiel
> _______________________________________________
> Accessibility-ia2 mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
