This is the proposed documentation for these attributes. The only new text is the last sentence:
This data is only guaranteed to be valid while the thread notifying the event continues. Once the handler has returned, the validity of the data depends on how the server manages the life cycle of its objects. Also, note that the server may have different life cycle management strategies for controls depending on whether or not a control manages its children. Lists, trees, and tables can have a large number of children and thus it's possible that the child objects for those controls would only be created as needed. Servers should document their life cycle strategy as this will be of interest to ATs or script engines accessing data out of process or from other threads. Servers only need to save the last inserted or removed block of text and a scope of the entire application is adequate.
Is this acceptable?
The AT should be able to get all text by specifying -1 on the endOffset.
Today Notes 8 returns an error. The code will be change to return all in Notes 8.0.1.
endOffset < startOffset should be an error.
Today Notes 8 does not return an error. Windows Eyes doesn't rely on this working.
Pending input from Freedom Scientific to determine if they have a dependency on being able to use endOffset < startOffset.
If endoffset > actual end, should the result be an error or the full string?
Notes 8 returns E_FAIL.
Any objections to this behavior?
There is a concern that IATable has a limitation of children being cells. Andres requested support for the case where the children are rows which in turn have cells as children.
There is production code relying on the current IDL.
Is this an issue with the IDL code or just an issue with the names of the variables and methods. Can the interface seen by the AT be independent of how the tables are actually structured within the application? Even if the structural parent of a cell is a row, could the presented structure show that the parent of a cell is a table? Can the problem be fixed in documentation with documentation describing that the actual structure can be different than the presented structure?
Deprecation of IA2_EVENT_TEXT_UPDATED
IA2_EVENT_TEXT_UPDATED appears to be redundant with IA2_EVENT_TEXT_CHANGED.
Linux has object:text-changed:inserted/removed.
Are there any objections to documenting that IA2_EVENT_TEXT_UPDATED is deprecated and should not be used?
IAValue - Issue raised by Aaron
AT-SPI uses a double for the parameters. IA2 uses a VARIANT. This was influenced by UNO (OpenOffice) which uses a type of "any" and Java which uses a super-type of "Number".
ARIA allows for values to be from sets of strings like "low", "medium", "high".
The current IDL gives access to these strings.
Are there any objections to the current IDL (since it provides access to string values)?
Note that ATK / AT-SPI would need an enhancement.
There is a related issue of how the AT would discover the set of strings (choices) if the AT needed to present them to the user.
They could be passed to the AT via IAccessible2::attributes
They could be passed to the AT via a new IAValue2 method.
However, IAAction is provided for fetching strings related to a set of choices and for activating these choices.
Is this an acceptable solution?
IA2::relation/relations - Current design is a performance problem for Firefox - Issue raised by Aaron.
HTML has label for but not label by. FF would like to provide labeled by. In order to do this it has to search the DOM for text which could label a control. This would be a waste of time if the AT is not looking for a labeled by relation. Aaron is requesting that IA2::relation be changed to take an integer defining one of the existing relations. IA2 relations are defined as strings so a matching enumerator would also be needed.
Some problems are:
ATK has the same problem.
Any dynamically defined relations would not have a related integer and would not be accessible via IA2::relation.
Aaron and Sina have discussed means to make the creation of the labeled by relation faster
using a hash/cache
looking nearby instead of through the entire DOM.
FYI from Aaron:
It turns out that most users of MSAA/IA2/COM may experience strange bugs where their calls are not returned. This often indicates a crash in the application they are trying to make accessible. However, the RPC mechanism is wrappering the MSAA calls in _try/__except (Structured Exception Handling), and hiding the crashes. This can lead to the failure to diagnose and eradicate critical errors in the MSAA/IA2 server -- in other words, strange, intermittent bugs that are very difficult to deal with. I suspect we need our testing tools to really help here, by exercising the server implementation in process.
This can be an issue for clients as well.
For an in-process client, if the server gets an exception the client should either return with an error code after trapping the exception or let the exception escape and not stop the show.
Hopefully, the RPC mechanism used by out-of-process clients returns a specific COM error code when the server causes an exception instead of just hanging the caller. There should be documentation that such an error code should be expected. The client needs to check the result of MSAA/IA2 calls for S_OK, the remotely trapped exception value, or any other normal MSAA/IA2 failure. (MSAA/IA2 has a different definition of failure error codes than normal COM: see http://msdn2.microsoft.com/en-us/library/ms695690.aspx)
Python wrappers - Michael Stewart
Waiting for IBM approval to release as BSD.
Waiting for code review.
Inspect tool - Mike Squillace
Eclipse - Larry Weiss, Barry Feigenbaum
Firefox - Aaron Leventhal
Documentation of memory management issues for [out] parameters - the following need to be understood and documented.
No progress last week.
Here is a rough first draft:
BSTRs need to be SysFreeString'd at end of life; ditto for when they are in structs or arrays.
COM interfaces need to be AddRef'd when used and Release'd at end of life.
Single longs, HWNDs, booleans, and structs are allocated by the caller and passed by reference. The marshaller does all the memory management. (I don't believe there are any structs with BSTRs or interface pointers.)
Arrays of longs - the server allocates the top level array and anything it points to; nothing needs to be free'd by the client. The marshalling code handles freeing anything on the client side.
TBD: How are VARIANTs handled? Like interfaces? These methods return VARIANTs: IAHyperlink::anchor/anchorTarget, IAValue::current/maximum/minimumValue
TBD: Are arrays of IUnknowns, e.g. IARelation::targets, correctly specified as **IUnknown?