Are you executing this automation from the other automation  or this is the first automation needs to be executed when you start ?

This automation is called from a previous one, but it gets through that one fine.

Here it is though:
Thanks,
Ryan

Ryan,

The usekeys shouldnt have an impact on the control not being able to match during runtime at all. If the control is failing to match during Runtime, it is likely due to to either a non consistent  match rule or the autx not giving the control enough time to match. 

Since you are using clones for the control and the time limit that is set in your autx is 10 seconds, I would lean towards not giving enough time for the control to become matched. Cloned controls can have a slight overhead in the matching process since it needs to matched several control objects of the same type. 

I would suggest to use the default waitforcreate with no timeout parameter. The default waitforcreate has the default timeout settting of 30 seconds. If the control can be matched prior to the 30 seconds have expired, the autx will continue without expiring the remaining seconds.

Hi,

I was trying with the default WaitForCreate at first, but this wasn't working so I shortened it to speed up testing. I have just tried again though and it still doesn't work after 30 seconds.

I think you are correct about the match rules. They are not picking up the form during debugging, but they are during interrogation. Could this not be because it is looking for another instance of the form, because of the way the automation is asking for keys?

The match rules for this form are:
Window Text Match Rule: "Motor Claims Menu"
Window Class Name Match Rule: "ThunderRT6FormDC"

I appreciate your help so far.

Thanks,
Ryan

I have tried with many other match rules, but I come across the same issue where they match during interrogation but during debugging, they do not.

Ryan,

What do you see in the logs?  Look for the Category=Adapters and the Message that starts with "Control is matched".  This is the entry that you see when the control is Created.  Another interesting entry is Catorgory=Keys and the Message starts with CreateClone.  This will appear when you are using keys and will appear shortly before the Created event.

I recommend starting your solution and manually navigating so that your situation happens.  Manually note at what time you did each step.  Then go back and review in the log what happened.  You know what to expect - do you see it in the log.

Jeff

Hi Jeff,

That looks very useful. This is the first time I've used Runtimelog however, so it is currently hurting my head. I'll need a little time to make sense of it. I will get back to you.

Thanks,
Ryan

Ok, so in Studio_Log4Net.txt I can see all of the messages stating that the form and all controls have been matched - I'm assuming  this is during interrogation.

In runtimelog.txt, I can see no such messages. Doing a search for the control names returns nothing at all, so I'm not entirely sure what I'm looking for there Jeff. The logs prove that my form is matching during interrogation, but not during runtime. I'm not sure where to go from here.

I've tried reviewing my match rules and using different sets of them, but they always match during interrogation and then not during runtime...

Where would you go next?

I've tried scouring the log for messages where it states it has tried to match, but failed, but I can't see any.

Hi Ryan,

Logs can be a bit intimidating, so using a text editor that can filter out only the lines you want is essential.  TextPad or Notepad++ are pretty helpful at that.  Once you eliminate all of the lines that you don't want, it gets a lot easier.  Make sure you have Verbose logging turned on.  You access that in Studio via the Tools --> Options menu item.  Choose OpenSpan and then set the options as in these screenshots.

These settings will enable logging for RuntimeLog.txt.  Use that log as all of my samples will come from that.

The controls will be named a little different in the RuntimeLog than what you found in the StudioLog.  The controls name will contain an ID that is generated at runtime.  So search only for the name you gave it in your adapter, not what you found in the StudioLog.

Let me know if this helps. 

Jeff

Can you share a little from your adapter?  It will help to see the controls you are using with the Properties page and match rules. 

If you navigate the application manually the same as your automation you should be able to just focus on the Adapter category lines with the Message = "Control is matched." (Created) or "ControlBase.Detach" (Destroyed).  Ignore any other lines until you can determine the Created/Destroyed patterns.

Hello!

This is now being handled through a support ticket.

Regards,
Lochan  |  Community Moderator  |  Pegasystems Inc.