SSO enabling an in-house developed application (e.g. VB) using the Parent command

Issue

Customer is trying to SSO enable an in-house developed VB application. They used the windows wizard to enable it but SSO is not working as expected. They start the application and nothing happens.

They manually edited the application definition and were able to enter data into the fields and logon using type commands as per the following section;

#========================= 

# Logon Prompt 

#========================= 

Dialog 

Title “Database Login” 

Class ""ThunderRTForm"" 

EndDialog 

Type –Raw $Username 

Type –Raw “T” Type –Raw $Password 

Type –Raw “N”

However, typing specifically into a Dialog ID (e.g. Type $Username #1001) is the most efficient method of SSO enabling an application and should be used where possible.

You typically only use Type –Raw if Dialog IDs of username and password fields change every time the application starts up (due to the backend application programming) or for logon failure messages because the window is often not recreated, we sometimes need to use Type –Raw to send keystrokes to it.

Cause

When SSO enabling an application the Dialog IDs of the username and password fields are typically required and SecureLogin enters the stored credentials into them directly.

In the example below, to specify Dialog IDs correctly, the relationship between the Title of the window and the User ID and password fields must be established in the application definition.

By default, when using the wizard, SecureLogin assumes the username and password fields are a direct “child” of the Title (as it typically the case). The wizard creates a Dialog/EndDialog block that instructs SecureLogin to react to a prompt (i.e. logon prompt) with specific and unique characteristics.

However, in the logon prompt below, the User ID and Password fields exist within a Frame (highlighted in red below). The frame is a child of the Title, and the User ID field is a child of the frame. This means the Dialog block needs to be modified.

Solution

The customer edited the Dialog/EndDialog block and added the Parent command. They used the Window finder to establish the relationship between the Title and the “User Id:” and “Password:” fields and discovered it was in a frame. See the knowledgebase article on the Window Finder for more information.

The tiered relationship between the User Id field, the frame, and the Title means the Parent command must be used to enable this application. The Parent command is often used to enable VB Applications because they typically contain frames.

If you have used the Wizard to check Dialog IDs and you know they are correct but SecureLogin is not entering the username and password, you typically need to use the Parent command to establish the relative location of the username and password fields to the window title.

The tool SLScriptBuilder.exe will assist you with creating application definitions.