Robotframework-WhiteLibrary : Windows app automation : Click button keyword is leading to failure - windows

We are trying to automate a windows app which can be accessed only via Citrix Receiver, using Robotframework-Whitelibrary. I was able to launch the Citrix Receiver successfully. But Attach Window , Click button after that are not functioning. "Could not find a window titled " Citrix Receiver" is the error that is displayed. Without the "Attach Window" command , I wont be able to access any elements inside the application. I am not sure what I am doing wrong here. Test & Failure information below.
*** Test Cases ***
Test1
Launch Application ${Test Application}
Sleep 3sec
Attach Window Citrix Receiver
WhiteLibrary.Click Button text:Open
| FAIL | AutomationException: Couldn't find window with title Citrix
Receiver in process 17020, after waiting for 30 seconds at
TestStack.White.Factory.ChildWindowFactory.WaitTillFound(Func`1 find,
String message) at
TestStack.White.Factory.WindowFactory.CreateWindow(String title,
Process process, InitializeOption option, WindowSession windowSession)
at TestStack.White.Application.GetWindow(String title,
InitializeOption option)

Solution :
I had to do the following , Launch & attach the application and then attach window.
After that i was able to find the element in the app.
Launch Application ${Test Application}
Attach Application By Id ${pid}
Attach Window window_title=Citrix Receiver

You can use
#{windows}= Get Application Windows Locator
${wind_length}= Get Length ${windows}
log to console ${wind_length}
#above code to see how many windows are the in the application
#you can use index to switch window
Attach Window ${windows}[0]
#will attach the window in '0'th index

Related

Window/Dialog name is not being captured while recording script for Desktop Application in UFT

How can I capture the Window/ Dialog of a Desktop Application using UFT when the Window/Dialog Name is not getting reflected while recording the Desktop Application using UFT. Have tried using Object SPY to capture the Window/Dialog Name, and the Window is getting detected also but it is not able to identify elements in that particular window when the Script is Run in UFT

Screen Sharing with Applescript and Automator

Desired Results:
1. Open Screen Sharing.app
2. Input desired IP address and connect (changes depending on environment)
3. Auto Mute Microphone
4. Wait for session to connect
5. Auto switch to Observe Mode
6. Session is complete and Screen Sharing.app is closed
7. Auto UnMute Microphone
What's been done and needs:
1. I have successfully done steps 1, 2, 3, 6, and 7.
2. I am stuck trying to find a way to trigger the Observe Mode without using a timer. If the desired connection isn't complete within the designated time or the window is not selected, it will not work and an error will occur.
3. I am using a combination of Automator and Applescript. Most of the items are setup by Applescript.
My question:
How can I tell Automator or Applescript to wait for Screen Sharing to finish connecting before proceeding with the remaining tasks?
Except GetUrl instruction, screen sharing app is not scriptable, then you cannot ask it if the vnc connection is on or not. Screen sharing app has an internal timeout which triggers an error window ("can't open...") after sometime.
So you can't know when the screen sharing will have open the windows or just the error dialog. The work around I used is to check, before opening vnc url, that your IP address answers to ping requests. But you may have some servers which don't answer !
The second part is easier because the switch to observe mode can be done via keystroke (screen sharing menu) with script bellow :
tell application "Screen Sharing" to activate
tell application "System Events"
tell process "Screen Sharing"
keystroke "x" using {option down, command down}
end tell
end tell
Of course, this is only valid once screen sharing has open the vnc window. And you must allow, in system preferences, the GUI scripting via your application.

How to determine title and additional infos from an open window for use with Autohotkey?

To access and control a window, dialog or popup with Autohotkey the title of that specific window is needed. For some windows the title can be read directly if its visible, but some windows hide it. The window class and the exe (ahk_class and ahk_exe) aren't visible at all. How to gather this information reliable?
Use the Window Spy tool, which is installed together with AHK, it can be started various ways:
Right click the tray icon of a running AHK script and select Window Spy
Start the AU3_Spy.exe in the AHK installation folder
Use the Windows search to search for Window Spy
You will get a window called Active Window Info with various infos about your current active (topmost) window. The first box is the one you need.
Example
The box gives title, class and .exe to detect the target window of which every line can be used to identify the window. Now you should activate the window you want to address and copy the information.
Hint: You can (un-)freeze the display with Win + A

Cannot Get Rid of Application Window After Application Crashes

I'm trying to debug a VS 2008 command-line application running under Windows XP. The application has been crashing (access violation), and I am catching the crsah in the debuuger. After looking at the call stack, etc., I tell the IDE to "Stop Debugging". The application window remains, but the process does not appear in Task Manager. Nothing happens when I click the "X" in the upper-right corner, though I can minimze / restore the window. The process is normally shut down by pressing Esc. It does not respond to this keypress.
I cannot even get rid of the application window by attempting to reboot XP. The machine will not reboot; it simply ignores my command to do so.
The only way I've been able to get rid of the application window is to do a hard power cycle. Ughh...
Does anybody have any suggestions on how to clean up this lingering application window after the application crashes?
Thanks,
Dave

Vista Window Focus Problem

I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.

Resources