The issue: There is a concern that IATable has a limitation of children being cells. Andres requested support for other structures such as the case where the children are rows which in turn have cells as children. There is production code relying on the current IDL. And compatibility with Linux is important. However the IDL should provide for the requested use case.
Summary of prior consensus:
The concept of a child index should be changed to be a cell index which is not necessarily related to IA2::indexInParent. Since the IDL is currently frozen this will be handled in documentation. The methods of interest are:
HRESULT childIndex ([in] long rowIndex,[in] long columnIndex,[out, retval] long *childIndex)
HRESULT columnIndex ([in] long childIndex,[out, retval] long *columnIndex)
HRESULT rowIndex ([in] long childIndex,[out, retval] long *rowIndex)
If the table manages its children and generates an active decendant changed event with a child ID, the AT can determine the row by using that ID on the calls to rowIndex/columnIndex.
A remaining issue:
If focus events are fired from the cells, there needs to be a way to get the row and column indexes. There are two possibilities:
Use IA2::uniqueID as the child ID when firing the event. The table can map uniqueIDs to row/column indexes.
The AT can sense a ROW parent object, use indexInParent (CELL in ROW) as the column index, and use indexInParent on the ROW object (ROW in TABLE) to get the row index.
The latter is simpler. Is it acceptable?
What are the remaining issues that need to be discussed and resolved?
IAValue - Issue raised by Aaron
AT-SPI uses a double for the parameters. IA2 uses a VARIANT. The current thinking is that IA2 should be documented to indicate that the VARIANT should always be a double. There are two use cases related to conveying end user usable text related to the corresponding doubles that IAValue would return:
If there is a related string for any controller positions return it via get_accValue (MSAA convention).
If there is a related text area that changes (like the slider on the Privacy tab of Internet Options) use a controllerFor relation.
Issues related to Linux ATK were raised but will be deferred for that group to discuss. The suggested time frame is when ARIA is implemented in Firefox. The possible Linux solutions are are:
Use accessible name to provide an end user value and if the control is labeled use the labelledBy relation.
Use accessible name for the label and update the label as the slider moves, e.g. Color - Blue. The slider numeric value would still be presented (via accessible value), but the name change event would also cause a presentation (afterwards) of the associated displayed string too. The displayed effect is presented to the user so it is likely to be implemented.
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?