Hi. Getting this to the top since we need to get attributes API changes together with relation changes.
In general Pete's proposal looks fine with me. Probably we might want to return two arrays one is for name, another one is for values. But I don't have strong opinion. Does anyone have suggestions, objections? Looking forward to hear your opinions. Thank you. Alex. On Sat, Oct 24, 2009 at 1:47 AM, Pete Brunet <[email protected]> wrote: > Thanks for the input. How is this then? > > Create IA2_2 > - remove: attributes > - add: > - HRESULT attributeValue ([in] BSTR name, [out, retval] BSTR *value) > - HRESULT attributes ([out, size_is(,*nAttributes)] BSTR **attributes, > [out, retval] long *nAttributes) > where the return values are in the form "name:value" > > Is it bad form to use the same name, i.e. "attributes", for a replaced > method? Should I name it something like "attributeList"? > > IAText2 would have the same changes. > > IA2 and IAText with their attributes method would be deprecated but still > useful until everyone gets a chance to switch over. > > Pete > --- > Alexander Surkov wrote: > > Hi. > > I think in general it's enough to have a method that returns attribute > value by its name. The method that returns an array of all attributes > is more helpful for debugging rather than in real life I assume > (please correct me if I'm wrong) to see what attributes are exposed at > all. But any way I think it should be nice to have method like this. > > So we could add these methods into the spec, servers will implement > it, clients can start to use them in future when servers will achieve > the status of official current version. > > Alex. > > > On Fri, Oct 23, 2009 at 7:04 AM, James Teh <[email protected]> wrote: > > > On 23/10/2009 2:04 AM, Pete Brunet wrote: > > > We can add the following to IA2::attribute and IAText::attribute: > HRESULT ([in] BSTR name, [out, retval] BSTR *value) > > > This looks good. Note, however, that this would require a new interface > due to the new method. > > > > Is an array of attributes also needed or should we stick with the > existing method which returns a multi-attribute string and thus the > required parsing? > > > The array is probably cleaner and more "correct" (no string parsing, > handling escapes, etc.), but having said that, multiple ATs (including > NVDA) already rely heavily on the old behaviour. This may be one of > those cases where it's simpler to leave it alone. Having said that, I'd > certainly be happy with an array. > > Jamie > > -- > James Teh > Email/MSN Messenger/Jabber: [email protected] > Web site: http://www.jantrid.net/ > _______________________________________________ > 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 > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
