Adapters, Elements, Lifetimes

Class library usage, coding and language questions.
fk4rx
Posts: 3
Joined: Mon Oct 09, 2017 12:49 pm

Adapters, Elements, Lifetimes

Post by fk4rx » Fri Dec 11, 2020 10:33 am

Hello

Despite working with Ranorex for >3 yrs, I have never understood what the Element object underneath an Adapter object really is, what their relationships are, and how long these objects "live". I unsuccessfully tried to find explanations in the API documentation and in the User Guide, so this forum is my last chance ;-) OK here are my questions:

(1) for a given Adapter object (e.g. of type Ranorex.Button), WHY is there also an Element object beneath? What's their difference?
(2) are the Element objects created as a result of the Ranorex injection into the AUT? If not, who creates them?
(3) how long do Adapter objects and Element objects "live", e.g. after the control in the AUT is no longer shown?
(4) what's the real meaning of the Adapter.Valid property (the documentation is mysterious...)?

Addendum to (3): for example, I have observed than an adapter's screen rectangle changes to 0,0,0,0 when the corresponding control in the AUT is no longer shown in the GUI, however the adapter (and element) still "lives" ... but for how long?

I am looking forward to some helpful insights into these concepts ... thanks in advance!

michael.wowro
Posts: 4
Joined: Thu Feb 10, 2022 2:03 pm

Re: Adapters, Elements, Lifetimes

Post by michael.wowro » Fri Sep 16, 2022 11:37 am

good questions!

csaszi89
Posts: 31
Joined: Mon Jan 17, 2022 12:10 pm

Re: Adapters, Elements, Lifetimes

Post by csaszi89 » Sat Sep 17, 2022 8:52 pm

Hi,

I am not a Ranorex API architect/developer, but I was browsing the code and tried to find some answers of your questions.
(1) Elements represent items in the UI tree, they do not have any control-specific capabilities, they are just stores information about the associated control.
In contrast, Adapters "adapt" some control-specific behaviours and each Adapter stores its own Element to be able to interact with the UI. For example, when a PressKeys method is called on an InputTag, then the keyboard action is executed by the help of the Element's properties.
(2) I do not know exactly what Ranorex injection does, so I am not sure, but as I wrote earlier, Elements represent items in the UI tree. Probably, they are created by the API itself when a search mechanism is called.
(3) Lifecycle of Adapters and Elements is managed by the test itself (see example below). By default, they are created when the associated repository item is called and they are disposed when the creation context executed.
In contrast, the controls of the AUT live until the AUT disposes them. They are managed by the application itself. Basically (lets assume), when a form is closed then the contained controls are disposed and they are no longer Valid.
(4) This is the point where Valid property comes into the picture. This property identifies whether the Element is still available in the UI tree. In other words, whether the control still exists in the AUT.

Screen rectangle behaviour is caused because the Element gets invalid. The AUT control was disposed when the test asked about the screen rectangle property. The control could not give valid response, therefore the property was initialized with default values: 0,0,0,0

Example:

Code: Select all

void ITestModule.Run()
{
    var myInputField = myRepository.Instance.MyApp.MyForm.MyInputField; // Element is searched in the UI tree, Adapter object is created at this point
    var isValid = myInputField.Valid; // true
    // at this point we close the AUT form, so we assume that form controls get disposed in the AUT
    isValid = myInputField.Valid; // false
    // just keep in mind, myInputField object is still living at this point, that is why we can still call its properties
} // myInputField object gets disposed after code module executed
Hopefully, I could help to get one step closer to the secrets of Ranorex API.
Of course, an official developer answer is also welcome!
Best regards,
Gyuri