Addition of IAText::defaultAttributes - raised by Aaron
In the process of adding text attribute support for FF3, the FF3 a11y team noticed that ATK has a method for returning default text attributes. See atk_text_get_default_attributes. Such a method in IA2 in conjunction with a method that returned only the changed attributes would be helpful on the AT side to be able to tell the user what attributes had changed and it would be helpful on the server side so the app would only have to gather up and present the text attributes that had changed.
Since IAText::attributes is already in use its behavior can't be changed. But should it be deprecated in favor of IAText::defaultAttributes and IAText::changedAttributes?
It should be noted that this issue was not raised by the AT or app developers during the implementation of IA2 in Notes 8.
The DSW, DSP, and DEF files are not yet published, but are now available via bug 110.
The DLL needs to be built by a non-IBMer and published. Larry Weiss indicated that he would do it as time permits.
The IDL has is frozen and needs to be submitted to BZR.
There have been no changes since the March 26 version.
Prior to publishing it on the main page the 3/26 version is available via bug 111.
Inspect tool - Mike Squillace
Eclipse - Barry Feigenbaum
Firefox - Aaron Leventhal
Waiting for IBM legal approval to release as BSD.
No progress last week.
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?