I currently have a Microsoft Outlook add-in that I would like to run automated testing on. I can't seem to find much out there on automation of Outlook so any advice would help. A quick run down of what the script should do is simply open Outlook, click on the correct tab containing the add-in, open the add-in (will appear in a pop up window), and fill out the necessary fields in the add-in and submit. This should all be done without interfering with the user (no moving the mouse etc).
I've taken a look at AutoIT and it seems to be able to handle what I want to do, but I wanted to see if there was anything out there that would be better suited for this task. Thanks for any help or advice.
For anyone interested in the answer, I'm using a combination of AutoIT and
Selenium to handle my automation. This link was extremely helpful.
Related
I am using WinAppDriver to automate my LabVIEW app UI testing. Inspect.exe can detect top level of active window but couldn't locate element inside the window.
So I couldn't get the text inside the window. Does anyone know how I could get the text?
Thanks!
Mary
As it was said, standard UI automation tools do not work with programs written in LabVIEW. However, there are alternative solutions such as LabVIEW UI Automation Tool. You should check this out, it may be helpful for you.
Whenever I have an add-in open in outlook, it closes immediately when I open a different email. Is there a way to keep an add-in open while I browse through multiple emails? Or is outlook coded in such a way that forces the add-in to close every time you click on a different email?
Thanks.
As far as I understand your questions you are the user of the Outlook Add-on. If this is correct, you will not be able to change this behavior. Every time you switch the item you would need to click to invoke the add-on once again. You may also contact the developers of this add-on and request them to implement a pinnable taskpane with explanation of your business case.
Well, if I was wrong and you are the developer of this add-on, you should look at pinnable taskpane in Outlook. This would cover exactly the case you have described. What you would need to do is just support VersionOverrides v1.1 schema in your add-on manifest as well as register and implement the Office.EventType.ItemChanged event handler in your add-on JS implementation.
I have one windows form UI wizard as custom action in MSI setup project in Visual Studio 2013. During installation one small progress bar dialog appears on top of the UI. This dialog also has a Cancel button and text like 'Please wait while Windows configures....'
Can we hide or disable this dialog somehow? Can we disable the Cancel button on this dialog? Or can we take this dialog behind the main UI so that user will not be able to click Cancel? Or Can we detect this Cancel button click event and handle in custom action?
There's no good answer to this, so basically this is just information.
The Windows Installer architecture expects all UI to be done in the first UI sequence, that's where data is entered. You probably understand this from the vast majority of other setups that do this. The execute sequence is intended to be silent except for errors and a progress bar. When Visual Studio setups allowed installer classes as a way for people to run managed code custom actions I don't think they expexcted people to have UI there. It often doesn't work because of the STA/MTA thread differences for message pumps, and since Windows Installer itself knows nothing about your custom action showing UI (there's not supposed to be UI!) it still believes it has the user's focus. The other issue is that many customers expect to be able to do silent installs, your requirement for a UI wizard defeats this.
I think some people have tried to solve your problem by enumerating all the Windows on the system to find the Windows Installer one and forcing it to the background, but I haven't seen anything recently on this or any code examples.
In your case, if your UI data can be collected up front with one of the canned UI dialogs then try that. Unfortunately VS setups don't give you a way to validate the input. If the UI wizard is for the app itself then it's usually easier to do it when the app first runs, as well as being easier to test and debug, being able to run later to reconfigure, and avoiding this kind of issue.
The limitations of VS setups include not being to design your custom dialogs to collect and validate input in the expected way at the beginning UI sequence. Also you cannot disable the Cancel button because VS custom actions run after everything is installed, which is too late to send the message saying "disable the cancel button". The overall issue is that you're fighting the limitations of VS setups, and another tool might be a better way to go, or have that UI wizard run at first boot of the app.
I am able to hide the progress bar dialog itself using Win32 APIs.
I am looking for a lightweight solution that would allow me to detect which form/ dialog is open in an application, then emit some keystrokes / mouse moves and clicks. I do not have control over (nor the source-code for) the application.
I am familiar with MacroMaker, also testing products like SQA / Mercury offer similar functionality. The last time I had hands on exposure in this are is late 2004, I welcome any pointers to bring my knowledge up to date.
AutoIt is a scripting environment for Windows with a long history. It's quite easy to use and flexible to do things like detect the open window or dialog, change to another one, type something, etc. I would definitely recommend it.
In case anybody is curious, in the end I decided to use Microsoft UI Automation. Here is nice intro:
http://msdn.microsoft.com/en-us/magazine/cc163288.aspx
I often see all this crazy stuff with Apple scripting, involving telling menus and menu items, and UI elements and all that crazy soft of stuff to do things. I don't mind that it's kind of a crazy way to get things done - as long as it works - but my question is this: How do you debug that stuff? I mean, how do you know what your options are?
I have apple script editor and script debugger, but I'm not sure how to use them to see what the options are. I've tried searching with google but I haven't come up with anything.
I do some web development so I'm used to using Firebug to examine the DOM of a web page, I just assume that there should be something easy and similar to help with Applescript.
Thoughts?
I'm not sure if you're asking how to script the GUI or how to tell which GUI elements are available in an application. If the former, try starting with Graphic User Interface (GUI) Scripting.
If you want to find out what the GUI hierarchy is for an application, check out UI Browser, which will allow you to see the UI elements of an application and provide the information you need to target one of them.