I have been facing issue with automation execution of my script on one of the VM. I have automated the functionality of Saving a Document which is ideally a Windows Designed UI. I have tried using various technologies/tools like AutoIT, Python, Sikuli but the script halts if VM is minimized. It works perfectly fine is VM is open via RDP and I can see runtime execution. But If I minimize the RDP, the script halts at 'Save As' dialog box, none of the send keys (Cntrl+s) or (Enter) work via AutoIt script. Please help with some solution so as to have successfully execution of script even in minimized mode.
The reason why your script fails when it gets executed over a minimized RDP session is quite simple. GUI automation/testing tools need to have an unlocked, active desktop - otherwise the operation system thinks that it doesn't need to actually render GUI operations (which is time consuming) since there no user can that can see the rendered graphical user interface anyway. And programs don't communicate via GUIs normally ...
This is why QF-Test and other GUI automation/testing tools often have a note in their FAQs describing this kind of problem. For example FAQ 14 in the case of QF-Test, see https://www.qfs.de/qf-test-handbuch/lc/manual-en-faq.html
As described in the FAQ 14 on Windows 10 or Windows Server 2016 and in case of an RDP connection you need to modify the Registry. Go to
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
and add a new value
RemoteDesktop_SuppressWhenMinimized as DWORD having the value 2
After restarting you will then be able to minimize the RDP connections. However disconnecing or closing the RDP connection will probably still result in a failure.
You could try running tscon.exe RDP-Tcp#0 /dest:console as admin as mentioned here. This will disconnect your RDP connection but should leave all GUI programs running normally on the VM. I have personally used this with autoit on a VM and it worked OK. Of course you will not be able to monitor your script as it runs so this may or may not work for you.
Related
I made a python script that runs a graphical automation using pyautogui (mouse movements) over a huge number of PDFs.
The automation appears to need an active display, for the mouse movements and the PDF to be opened.
If I connect to the Azure VM (with Windows OS) with SSH and start the python script, I get an error from pyautogui as below:
pyautogui.FailSafeException:
PyAutoGUI fail-safe triggered from mouse moving to a corner of the screen.
To disable this fail-safe, set pyautogui.FAILSAFE to False.
DISABLING FAIL-SAFE IS NOT RECOMMENDED.
I have tried with the failsafe disable and still it doesn't work.
As I have read, this happens because there is no active display opened.
If I connect to the VM using RDP, the automation starts and works as expect until I minimize or close the window. When I do that I get the same failsafe error from pyautogui.
But I cannot keep the window open, because I would need to start the same automation on 16 more VMs.
Is there a way to run such graphical automations in Azure VMs or any other similar solution? Docker maybe?
Is there any solution to run or host VM machines with permanent active display opened? Is something like this possible?
I ended up using Virtual Box.
I first created one VM with the needed software and files.
You can start the VM in headless mode. Then show the VM in order to log in to Windows and start the automation script. Then you can close the VM window and let it run in the background. The graphical automation will still run ok in that case. PyAutoGUI won't crash as if there were no active display.
I cloned the original VM 16 times and split the work evenly between the VMs.
Using ssh I am able to connect to each VM and monitor the status of the automations.
It would be great if there were a solution similar to kubernetes that could help with the deployment of such automations and with the monitoring of the status, but until then this is ok.
I created a Python script that opens a certain software on my PC (the MetaTrader 5 software to be specific), does some processing, saves a file to disk, and closes the software. To have the script running in the background (in hidden / headless / background mode), I was advised to convert the script to a Windows task, since my initial approach using subprocess.Popen() and the STARTUPINFO instance seems to fail for any complex application (see John Hennig's comment under his reply here). Therefore, I created a .bat file and connected it with my new Windows task. Now I hit a roadblock though, since Windows tasks are typically set up with triggering time/frequency to be run automatically. In my case, however, I want the trigger to be an external Python script. Is this possible? If not, is there any other way to have applications run without their windows flashing up on screen?
I have very similar problem to this one : SetForegroundWindow in Remote Desktop Connection
Everything works when I am connected and watching the RDC, but when I'm not.. Nothing happens.
I am using python and pywinauto, trying to use SendKeys method : SetForegroundWindow returns 0, the same as GetLastError after that, so I have no idea what might cause the trouble.
Edit: I also tried other methods like BringWindowToTop, or SetActiveWindow, also I tried to sent alt key before changing windows - nothing worked.
If your pywinauto script works on remote machine, it cannot manage RDP window at all because RDP window is on your local machine.
To prevent lost of GUI context in RDP you do NOT need to minimize RDP window locally. RDP can lose focus safely, but minimizing leads to stop of any GUI related activity.
It's correct for any GUI automation, not pywinauto only. If you have a lot of test machines, the best way is having 1 master and many slaves. Master host can initiate and keep non-minimized remote sessions, slaves are running GUI automation scripts.
I am testing a piece of hardware which hosts an ftp server. I connect to the server in order to configure the hardware in question.
My test environment is written in Python 3.
To start the ftp server, I need to launch a special proprietary terminal application on my pc. I must use this software as far as I know and I have no help files for it. I do however know how to use it to launch the ftp server and that's all I need it for.
When I start this app, I go to the menu and open a dialog where I select the com port/speed the hardware is connected to. I then enter the command to launch the ftp server in a console like window within the application. I am then prompted for the admin code for the hardware, which I enter. When I'm finished configuring the device, I issue a command to restart the hardware's software.
In order for me to fully automate my tests, I need to remove the manual starting of this ftp server for each test.
As far as I know, I have two options:
Windows GUI automation
Save the stream of data sent on the com port when using this application.
I've tried to find an GUI automater but pywinauto isn't supporting Python 3. Any other options here which I should look at?
Any suggestions on how I can monitor the com port in question and save the traffic on it?
Thanks,
Barry
Have you looked at pySerial? It's been a few years since I've used it but it was quite good at handling RS-232 communications and it looks like it's compatible with Python 3.x.
Sikuli might provide the kind of GUI automation you need.
I was also able to solve this using WScript, but pySerial was the preferred solution.
I am creating Windows service class in Python that will eventually display a Window when certain conditions are met. Since (as I understand it) services cannot have GUIs, I'm trying to start up a GUI in a seperate process (using subprocess.Popen) when the conditions are right. This isn't working, presumably because the child process has the same privileges as the service.
So how do I start a process from a Python Windows Service that has the ability to display GUIs on the screen?
If you give your Service the Allow service to interact with desktop permission it will be able to create windows without the need to launch a subprocess.
As mentioned in this answer, you may have to (eventually) transition to a client-server model since Windows Vista and later no longer support direct interaction with users.