I use wscript to launch an application on my machine. I then use this app for 30 seconds before I kill it. I do this using python -
import win32com.client
import time
shell = win32com.client.Dispatch("WScript.Shell")
shell.Run("My App")
time.sleep(0.5)
shell.SendKeys('%f')
...
I was wondering if it is possible to ensure that the launched app receives the SendKeys instructions and not another app that I might accidentally give focus to under this 30 second period.
Thanks,
Barry.
Problem
how to guarantee a wsh script SendKeys event goes to a specifically targted application
Workaround
in lieu of a straightforward solution to targeting a specific process with SendKeys you can use the "wait" variant of ShellRun
Example
Change "Before" into "After"
Before
WshShell.Run(run_name)
After
WshShell.Run(run_name,1,true)
Related
I am working on automating an Android app. We have a screen that has a table wherein the cell values keep on changing in seconds. I have observed that it takes more than a minute for AndroidDriver to execute a single action.
I have read on some other forums about this and got to know that this is how the UiAutomator2 works and it has nothing to do with Appium. UiAutomator2 waits for elements to come to a static state and then performs the actions.
Since the dynamic elements on the screen are unavoidable, is there any workaround for this to make Appium scripts execute with good speed? Let me know what you all think of this. I will really appreciate your comments on this. Thanks.
Yes, that is right. It has nothing to do with Appium itself, but with UiAutomator. UiAutomator takes accessibility snapshots only when the application is in idle mode and the framework itself is not optimized for cases when there are constant changes in the page view. As a workaround, try to play around with waitForIdleTimeout such as setting it to zero or try with setting the disableWindowAnimation to true in the desired capabilities.
You could also try with running the following commands:
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0
As a last resort, you could ask for the developers to provide you with a special build that has the animations removed in the source code.
I had the same issue, my specific problem was that the mobile app had a timer in the UI, that was changing its value every second.
Looks like the driver was waiting for the DOM to become idle, so it was SUPER slow because of that.
This simple command fixed the issue for me:
# Python code
driver.update_settings({"waitForIdleTimeout": 0})
Additional references:
https://appium.io/docs/en/commands/session/settings/update-settings/
https://github.com/appium/appium/issues/14155
While executing runAppInBackground() for Android application through Appium the app gets restarted but when executed the same manually couldn't be able to reproduce the same. I Would like to deep dive into implementation of a runAppInBackground() method to reproduce the same issue in a manual way.
You need to look behind the code of runAppInBackground
From java client side (your test code) perspective, it is a single call to Appium server:
POST "/session/:sessionId/appium/app/background"
If you continue looking into where its implemented on server side, you finish with appium-android-driver function.
In short what it does:
Get current activity and package
Press physical Home button
Wait for time you provided as argument (seconds)
Bring up back in focus based on different conditions; from the code you can understand what activity is being started
Basically its a sequence of adb shell commands, that you can run from terminal.
My guess is that step 4 you did manually may differ from what Appium is doing: different activities/arguments for activity been called
I've created a simple python application running in raspbian using kivy. The application runs already nicely in full screen mode. however I would like to be sure it cannot be interrupted with ctrl-c or any other command using the keyboard, and the application must never lose focus if something happens in the OS (for example some kind of dialog opens - I'm not sure if this actually can happen). I'd appreciate things that should be taken care of.
My app doesn't need to be bullet-proof, but it should endure a "casual user".
You can catch Ctrl+c or other signals with the signal module.
import signal
def signal_handler(signal, frame):
pass
signal.signal(signal.SIGINT, signal_handler)
This code prevent the user to exit by sending the SIGINT signal, corresponding to ctrl + c.
Other signals: https://unix.stackexchange.com/questions/317492/list-of-kill-signals
I am in the middle of PT where application is checking for JailBreak, sooner it starts and the first screen user see is Alert that application is Jailbroken and click okay to exit.
My question: Is there a way to attach Cycript before application starts or start application with Cycript as it seems very late to change method when it is already called by application and I am on the close alert.
Please advise.
or advise If I can run application with GDB, rather than attaching with the process later -- same issue here, it is too late to attach to gdp after running the application because decision of JailBroken is already done.
I found this link which explains in detail about run time modifications using gdb as well as with cycript.
May be helpful for you or someone else.
I just encountered same question and I got over that by using choose() in cycript and function -[UIModalView dismissWithClickedButtonIndex:animated:]
Use choose(UIAlertView) to search all AlertView
Try figure out which one is your target and call [choose(UIAlertView)[i] dismissWithClickedButtonIndex:0 animated:0]
*i is the sequence you get in step 1
Is it possible to force stop a .wlua file? I figured that I would have to use the Lua Command Line to do this, but I can't seem to find out how to stop them.
If it's possible, how can it be done?
Because wlua.exe doesn't open the console window (that's the purpose) and you can't send Ctrl-C, the only way to terminate such application is to use Processes window in Task Manager. Note, however, that the process name will be wlua.exe for every file opened that way.
Of course, it's meant only to be used when the application isn't responding. Your GUI application should provide a way to close it, such as close button, listening for ESC key etc.