I execute a long running AS in the background. Sometimes it needs to activate (bring to front) an application (E.g., browsers in the background execute Javascript very slow and it might timeout. The fix is to bring the browser to the foreground.). If I am working on something else when this happens it is very easy to click on something in the window that was just brought to front, enter some text or something, which often interrupts the script.
Is it possible to block mouse and keyboard input for a few seconds in AS?
What typically happens is that the script brings a web browser to the front just when I am about to click something in the âmanualâ frontmost application and it happens so fast that I canât stop myself from clicking and suddenly the browser is in an âunexpectedâ state which breaks the script.
I donât do anything âwrongâ - the script works fine if the computer is left unattended. The problem is that it takes 1-2 hours to finish and that I sometimes need to use the computer when it executes and when this happens it is easy to, by mistake, click on something that belongs to the script which makes it into an unexpected state.
I didnât Imply that you,did something âWRONGâ. Just that there might be a better way to modify the script that it would continue properly whether the app is frontmost or not. But since you wonât share the scriptâŠ
i googled âmacOS disable keyboard input via command lineâ - which brings up multiple discussions that list various methods which may or may not work. you may already googled it yourself anyway. maybe some of them will work for you.
If I could add a full screen (maybe invisible) image on top of everything that received all input? I just need it for 3 seconds or so so I notice that the frontmost application has changed.
Hmm, I am not sure if I am off the mark here, but why donât you adopt a pragmatic approach:
Before bringing the browser in the foreground, make the script (or you script runner) frontmost and display a dialog annoucing the application switch. You could make the dialog give up after a couple of seconds to be able to run it unattended.
In this way the user getâs a rather fail safe (I suppose) warning to keep his or her hands off the keyboard or the mouse because an applications switch is imminent.
After the frontmost app gets relegated to the background again, you could restore the previous app using System Events to signal that the user is allowed to touch the mouse or keyboard again.
Or something the like.
While it may be possible to implement a workaround that could potentially emulate this, it would surprise me if an API is available that permits this as it would represent a pretty big security vulnerability.
Itâs also not something that should ever need to be done in a real-world situation, and if your use case does depend on this, itâs well worth considering whether the problem youâre wanting to solve can be approached differently.
Another red flag that points to an approach that might be rethinking is it being a âlong-running AS in the backgroundâ. Scripting, by its very nature, is not intended for big tasks that run for a long time (ie. more than a few minutes, not including idle time).
To reduce running time, make sure you organise your code so that the executing of JavaScript is done in as few calls as possible (preferably, all in one call), and then organise your AppleScript code to process the return value of the JS as the last step, also ideally all at once.
Generally speaking, it isnât usually necessary for a web browser to be at the front in order to inject some JavaScript into a web page (as long as the web page is still loaded into memory, i.e. not sleeping or hibernating). You also donât need to use a web browser at all to inject JavaScript: with AppleScriptObjC, a web page can be loaded using NSURLSession and NSURLRequest methods, and attached to an NSWebView (although a view doesnât need to be painted / displayed) in order to execute JavaScript code in the pageâs document.