Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Understanding the control life cycle

Updated on May 26, 2022

When a Studio project is started, all of the automations, adapters, and controls within the project are instantiated and populated with data. This process is known as deserialization. At this point, all of the controls within an adapter exist, but have not been matched. Because the controls exist, they are available for use within automations.

After the automations, adapters, and controls have been deserialized, each adapter within the project is started. You can control whether an adapter starts when a project is run using the StartOnProjectStart property. Use the StartOnProject property to control when an adapter starts after a project is run. While an application runs, controls may be matched and unmatched multiple times depending on activity in the application. For example, a pop-up dialog used to enter account information appears multiple times when interacting with multiple accounts in succession. When a project is stopped, all of the automations, adapters, and controls within the project are disposed with and removed from memory.

IsCreated and WaitforCreate

When a control is matched, it is considered created. Likewise, when a control is unmatched, it is considered destroyed. Developers can determine if a control is created using the IsCreated property.

IsCreated property
Automation surface showing automation block with IsCreated property.

Alternatively, developers can wait for a control to be created using the WaitForCreate method. When WaitForCreate is called, the automation stops until the control is either created or the timeout intrerval expires. If the control is created, WaitForCreate returns True. If the timeout period expires, WaitForCreate returns False. WaitForCreate will not wait for the entire timeout period to return if the control is created. For example, if the timeout interval is five seconds and the control is created within one second, WaitForCreate returns True in one second. However, if the control is not created, WaitForCreate returns False in five seconds when the timeout period expires. If WaitForCreate is called when a control has already been created, it returns True immediately.

Wait for create
Automation surface showing control with WaitForCreate method set.

Use the WaitForCreate to manage transitions when automating an application. Consider the following application flow:

User actionRobot Studio action
Launches applicationApplication starts.
User sees application launchingLogin dialog is created.
Enters user name and password and clicks EnterLogin dialog is destroyed.
Main form is created.
Clicks Open Account Toolbar buttonOpen Account dialog is created.
Enters the Account Number and clicks EnterOpen Account dialog is destroyed.
Account form is created.

Every time a form or dialog is created or destroyed a period of time elapses: sometimes less than a second, sometimes several seconds. If Studio were to automate the above flow and not wait for each new form to be created, an error displays, because the appropriate controls have not been created.

Consider the same flow as above but with WaitForCreate added:

User actionRobot Studio action
Launches applicationApplication starts
Calls the login dialog WaitForCreate
Login dialog WaitForCreate returns TrueLogin dialog is created
Enters the user name and password and selects EnterLogin dialog is destroyed
Calls the main form WaitForCreate
Main form WaitForCreate returns TrueMain form is created.
Automation clicks Open Account toolbar button
Calls the Account dialog WaitForCreate
Account dialog WaitForCreate returns TrueOpen Account dialog is created
Enters account number and selects EnterOpen Account dialog is destroyed
Account form is created

To simplify automations, most control methods and properties implicitly use WaitForCreate. This means that when a method or property is invoked in an automation, the control automatically waits to be created. For example, if an automation attempts to set the text property of a text box before the text box is created, the automation automatically waits for the text box to be created before proceeding and setting the text. If the text box is not created within the timeout interval, the automation throws an exception (ControlNotCreatedException).

Consider the flow again when using implicit WaitForCreate:

User actionRobot Studio action
Launches applicationApplication starts
Login dialog is created
Enters user name and password and clicks Enter (automation automatically waits for the user name and password text boxes to be created)Login dialog is destroyed
Main form is created
Clicks the Open Account toolbar button (automation automatically waits for the toolbar button to be created)Open Account dialog is created
Enters account number and selects Enter (automation automatically waits for the Account Number text box to be created)Open Account dialog is destroyed
Account form is created

When you use the implicit WaitForCreate functionality, automations are considerably less verbose.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us