When I try to run it and already changed the details in the env.json under devdata file, outlook app is launched but after it the ‘New Email’ button couldn’t be found.
Hi and thanks for testing our example. Can you please provide a screen recording on what happens on your desktop until that error is thrown?
Meanwhile, can you try debug the issue yourself by using our own windows-record script and even the Print Tree keyword for listing the available elements in the Outlook app?
Check the How to inspect and Recording headings under our docs for complete details. (alternatively you can also try with a path: locator – example)
That’s the result ^
When the robot runs, it will just open the outlook app and the process stopped at here, it won’t click the new email button to proceed the next step.
A screen video recording on how the bot runs and how the app opens
What happens when you run the windows-record script with --verbose and you click the “New Email” button during its run
Try with a path: locator (instead of the name: + type: one) and let’s see what it happens with this one
What is displayed in the logs when you run Print Tree keyword after controlling the main Outlook window (so we can track down the correct locator for the “New Email” button in your case)
About search depth
The library does element search depth by default to the level of 8.
This means that locator will look into 8 levels of elements under element tree of the root element.
This can lead into situation where element can't be found. To fix this it is recommended
to set root element which can be found within 8 levels OR
defining depth in the locator string to a bigger value, e.g. id:deeplyNestedButton depth:16.
Useful keywords for setting root element are Control Window, Set Anchor and Get Element.
You can also see depth in Accessibility Insights for Windows: your element 12th child on desktop element.
May I know why when I make the Set Task Variable as comment under the ‘Set variables for this task’ the final result printed as the email body is just ‘devdata\email_body.txt’, which means the ${email_body}= ${EMAIL_BODY}, but I didn’t see any line includes this ${email_body}= ${EMAIL_BODY}. I make the Set Task Variable ${email_body} ${email_body} as comment line is because I want to know how the Set Task Variable will affect the variable.
Set variables for this task
[Documentation] Sets necessary variables for the task to work properly.
Set Task Variable ${outlook_title} ${ACCOUNT_NAME} - Outlook
${email_body_exists} = Does File Exist ${EMAIL_BODY}
IF ${email_body_exists}
${email_body} = Read File ${EMAIL_BODY}
#Set Task Variable ${email_body} ${email_body}
ELSE
Set Task Variable ${email_body} ${DEFAULT_MAIL_BODY}
END
#That is the task log if I run the robot when I make the Set Task Variable ${email_body} ${email_body} as comment
This is due variable scopes, by commenting out that statement the content of the file is not available for other keywords. You can read more on this topic on official documentation at Robot Framework User Guide
So your usage of ${email_body} and ${EMAIL_BODY} are actually very confusing and probably an error. To make code more clear, use variable names that describe real intent, like ${email_body_filename} and ${email_body_text} instead.
Hi, I try using the windows-record --v command today, but the path is not shown, but only some of the details. What should I do to enable it to help me find the path automatically, as I found it’s annoying to find the path by myself
Yes, as @jippo highlighted, maybe you’re not on the latest library version (22.5.3 atm).
You can check the latest one either in PyPI or among the release notes. (if not already on our recommended newer Robocorp updates channel)
Also, ensure you run it with either -v or --verbose, not sure if --v will behave the same (although it works the same in my case). And that you follow the approach described in the example (opening a terminal with the robot env).
Can you do the same over Calculator and/or Notepad, because if you see a path there it means that for some reason the functionality is present in your environment but the logic isn’t able to correctly match the element you clicked with the one found in the tree in order to pull out the path: from it. (thing which I couldn’t replicate on my system)
Meanwhile, try with Print Tree max_depth=${13} (or even higher depths) after controlling the main window and look in the logs for what it prints. (you should see a Path: as well near every control listed in a tree-like manner, and hopefully that will unblock you for the time being; also don’t forget to paste the tree printing logs here so we can help you debug and understand the cause)