Re: Retaining an AXUIElementRef
Re: Retaining an AXUIElementRef
- Subject: Re: Retaining an AXUIElementRef
- From: Patrick Cusack <email@hidden>
- Date: Mon, 24 Jun 2013 22:34:22 -0700
Considering this, what is best practice for making sure you have the object you think you have cached? I can always check its title attribute. Is there a faster way?
Patrick
Sent from my iPhone
On Jun 24, 2013, at 10:19 PM, Patrick Cusack <email@hidden> wrote:
> Ok thank you. That explains everything. I thought I was doing something wrong. How did you know that about carbon apps? Is that in a piece of documentation?
>
> Sent from my iPhone
>
> On Jun 24, 2013, at 8:21 AM, Eric Schlegel <email@hidden> wrote:
>
>>
>> On Jun 23, 2013, at 11:03 PM, Patrick Cusack <email@hidden> wrote:
>>
>>> I am creating a cache of AXUIElementRefs for another application's gui objects. I keep a cache of these elements and periodically refer to them (check their titles, etc). What I have noticed is that if I examine these cached elements from time to time, it appears that the underlying UI object they refer to can change. I have two particular AXUI references that point to another object unrelated to what I have cached if activate certain features in the targeted application's gui. If I unactivate said feature, the references point back to my original targets.
>>>
>>> I have set up an observer on the application to query an AXUI elements that are destroyed, and I don't see my cached objects destroyed. How could the references I have cached be changed behind my back? I store the elements in a mutable dictionary. I caste them to (id) and add them to the dictionary. This wouldn't cause any issues I assume.
>>
>> The answer depends on the type of application that you're observing, and the type of object in that application.
>>
>> If you're observing a Carbon application, the AXUIElementRef contains an actual pointer (void*) to the corresponding UI element object in the other process. The pointer is not valid in your process, of course, but when you query state on the AXUIElementRef, the pointer is sent back to the target process and dereferenced there. If the UI element that the pointer points to is deallocated and another object is allocated at that address, it's possible that your query could return results from some other object.
>>
>> If you're observing a Cocoa application, the AXUIElementRef could contain two different types of object references: a simple numeric ID, or a list of numeric IDs and indices. Some UI elements in Cocoa (NSCells, NSViews, NSWindows) are assigned a non-repeating numeric ID for accessibility purposes when they are created, and this ID is used to identify them later when an accessibility query is made to that object. I wouldn't expect you to see incorrect results in this case. Other UI elements in Cocoa, however, are identified using a parent object identifier plus an index into the parent's children; for example, a table row would be identified by the table's ID plus an index into the table. In that case, if rows were to be deleted or inserted into the table, an AXUIElementRef that identified row 5 could start returning new state if rows were inserted or deleted prior to row 5.
>>
>> -eric
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Accessibility-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Accessibility-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden