Posted: 5 Oct 2016 7:35 EDT Last activity: 6 Nov 2018 20:02 EST
I am unable to complete a WaitForCreate on a form, I believe it is due to my use of keys. Could somebody please provide assitance as I am not very good with keys and knowing when and how to use them.
Below, I have a MotorClaimsWindow, which is a form of the application I have interrogated. I wish to do a WaitForCreate and then click a radio button on the form. However the wait for create always returns False. I have tried setting the key as Active or None, or setting the key as 0, but none of these options work.
I know there is likely a very simple solution but at the moment, I am stumped. Please could somebody help?
***Updated by moderator: Lochan to add Support Case number***
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
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.
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?
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.
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.
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.
Line 7990: | Automation: AWD2OutlayRecovery_P_FindRec - ExecutionLink From: AWD2CustomLookup.cmnu_FLR_CreateEmail.WaitForCreate() To: AWD2CustomLookup.cmnu_FLR_CreateLetterRFI.PerformClick() ID: 9bc717f6-030e-4251-8b8f-356dc51cc75e
So this is clicking an option in a context menu, which loads up a form named MotorClaimsMailWindow. The form does load up, but nothing on the form is ever matched. Everything Match related in the log after this is a fail, from what I can see. Here are some of the fails:
Line 7991: | MenuItemPathMatchRule failed for window [OpenSpan.Adapters.Windows.Targets.ContextMenuItem] - Path: Resend, Target Path: Break Relationship
Line 7992: | IsMatch failed - target: [OpenSpan.Adapters.Windows.Targets.ContextMenuItem]
Line 8028: | ActiveXFactory-29138285 | ModuleNameMatchRule failed for target AWDCmpts.DLL - Mode: Simple, Value: Simple|True|(User Culture)|ole32.dll, Target Value: AWDCmpts.DLL
Line 8029: | ActiveXFactory-29138285 | IsMatch failed - target: AWDCmpts.DLL
I'm still not sure what any of this means. I may raise a ticket with Openspan to see if they can walk me through it over the phone, as I think I am lacking too much in experience to decipher an answer from these logs.
Thanks for your help so far! If you have any more advice, I'd still be very grateful!
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.