I've just started to use the Google Apps Scripts Editor on Chrome on a Mac. The good people at Google added a shortcut for quickly running scripts, which on Windows is ctrl-R, and probably doesn't conflict with anything. Then they translated it to cmd-R on Mac, which globally makes sense. As a Mac user however, I'm used to using cmd-R to reload pages (as compared to F5 on Windows). The google shortcut takes precedence, meaning that each time I hit cmd-R to simply force updating the page (because it sometimes help to reload the page), it launches the script I'm viewing. I'm worried it may at some point execute a script that I'm not intending to execute at that particular time.
Is there any way to disable the google shortcut? I'm perfectly fine having to go and click the arrow, but I'm not fine risking launching a script when I don't mean to.
Unfortunately, there is no way to disable the shortcut keys in Google Apps Script. However, you can add a confirmation dialog box in your script to add extra layer of protection from running your script accidentally.
Example:
Code:
function myFunction() {
var confirm = Browser.msgBox('Are you sure you want to execute the script?', Browser.Buttons.OK_CANCEL);
if(confirm == 'ok'){
//insert your code here
}
}
Dialog Box:
Reference:
msgBox(prompt, buttons
Following #Nikko's suggestion I'm displaying a dialog box when the script is started (i.e. top-level), and when the answer is "cancel" I simply wait (Utilities.sleep()) for 5 minutes, and then again. This prevents the function from being executed until the script would be killed automatically, but more adequately it keeps the script execution dialog box displayed, in which you can choose to cancel the execution. So you don't have to wait 5 minutes, just click "cancel" while the script is doing nothing. Again, dirty, but works for me.
if(Browser.msgBox("Are you sure you want to run this script?", Browser.Buttons.OK_CANCEL) == 'cancel') {
Utilities.sleep(300000)
Utilities.sleep(300000) // just to prevent accidental execution in the last split-second
}
Related
I've been working on a browser extension allowing users to generate epub files from any webpage.
To use the extension, a user has to click on a toolbar button which opens a popup. On the latter, after specifying a config, the user clicks on "Generate". Here is my issue though:
When I use the download API directly, and specify saveAs to false (i.e the user is NOT prompted where to save the file), then the download is completed as expected and the file saved in some location.
However, when I do set saveAs to true --- which is what I want in the final version --- then once the user has selected the location under which to save the file, the download fails. My intuition is that as soon as the file location window pops up, the popup looses focus and dies, which makes the download impossible to resume.
Is that the explanation? And is there a way to prevent such a problem? I do not find my use case to be much of a stretch, and do not get why popups associated with browser actions are not allowed to loose focus for file selection.
Another weird thing is that I'm pretty confident this problem only appeared recently in firefox, since when I started developing the extension, I had no issue.
My intuition is that as soon as the file location window pops up, the
popup looses focus and dies, which makes the download impossible to
resume.
That's right...
Browser Action Popup is page and once page is closed, async operations will lose their reference. It is best to pass async operations to the background script.
You can use
runtime.sendMessage()
to pass a message to the background script to run the download.
You can also use the async
runtime.getBackgroundPage() to run a function in the background script but the first option works
easier as you dont need to wait for the async response as in runtime.getBackgroundPage()
I have the following AutoHotKey script to help me switch between different open apps, using a shortcut:
^!c::ToggleWindow("Chrome")
^!p::ToggleWindow("PowerShell")
ToggleWindow(TheWindowTitle)
{
SetTitleMatchMode,2
DetectHiddenWindows, Off
IfWinActive, %TheWindowTitle%
{
WinMinimize, %TheWindowTitle%
}
Else
{
IfWinExist, %TheWindowTitle%
{
WinActivate
;;; Tried using WinMaximize/WinRestore here but same result
}
Else
{
DetectHiddenWindows, On
IfWinExist, %TheWindowTitle%
{
WinShow
WinActivate
}
}
}
}
The problem is that for some apps it works only sometimes (for example, PowerShell and TortoiseHG Workbench) which is really frustrating. For other apps (Chrome, Thunderbird) it works always.
Here is what I've found so far:
If you explicitly minimize a "problematic" app then you can never activate/maximize the window using the AHK shortcuts. I'm not sure if there are other scenarios that prevent the shortcuts from working but this is one certain way to replicate the problem (at least for me).
Even in the cases where the shortcuts don't work, I can see that the target app icon in the taskbar is getting highlighted. I guessing it works somewhat halfway, activating the window but not actually showing it.
I think the problem is not restricted to AutoHotKey only because I can replicate this behavior just with the Task Manager. If I go to the 'Applications' tab, right click on on target app and choose 'Bring to front', the same thing happens. BUT, if I choose 'Switch to' instead, it works!
So, I guess my question is what exactly does "Task Manager->Applications->Switch to" do and is there an equivalent that I can use in AHK. My OS is Win7.
Try to put a #WinActivateForce in your script.
If you run AutoHotkey as normal user, it may be unable to manage program running as administrator (for example PowerShell). If that's the case, try to run AutoHotkey as administrator.
If you explicitly minimize a "problematic" app then you can never
activate/maximize the window using the AHK shortcuts. I'm not sure if
there are other scenarios that prevent the shortcuts from working but
this is one certain way to replicate the problem (at least for me).
According to AutoHotkey's release notes, this is a known issue which was fixed in AutoHotkey v1.1.20. (Released 1 month after this question was asked)
1.1.20.00 - March 8, 2015
Changes
Changed WinActivate to restore the window if already active but minimized.
Changed WinActivate to look for a visible window to activate if DetectHiddenWindows is off and the active window is hidden, instead of
doing nothing
I'm currently working on developing a user script for Firefox. Every time I've made a change, I have to manually refresh the tab with the script and reinstall the script. I want to do the thing that's asked in this question, but in Firefox.
Is there a way to automate this so that the user script automatically gets reinstalled every time I save the file in emacs?
If I understand your quesiton correctly you want to avoid the hassle of reinstalling your userscript each time you save it in your editor.
Here are the step-by-step instructions.
Install Greasemonkey in Firefox.
Install your script in Firefox (via Greasemonkey).
Firefox Menu -> Tools -> Greasemonkey -> Manage User Scripts -> Right-click on the script you are working on.
(a) Select "Edit" to open your script in your default editor (emacs?).
or
(b) Select "Show Containing Folder" to open the folder containing your script and subsequently open it with a custom editor (e.g. emacs).
Update the script in your editor as needed and the modification will take effect the moment you save it. Yet you still have to refresh the web page on which your script runs in order to see the result.
I use firefox for my web development and I bet most of you guys too. I've been doing a lot of form development recently and this annoying message
"To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier."
is just beginning to piss me off.. I mean, come on! I don't need protection on my localhost, thank you! So, my question is: are you aware of any config, hack, plugin to suppress it? If not, how do you live with it?
Apparently there is neither configuration option nor extension to turn off this annoying confirmation window.
However, the workaround I use is as follows.
Download and install application AutoHotkey from: http://www.autohotkey.com/
Create the following script:
^f5::
Send {f5}
sleep 100
Send {enter}
Save with .ahk extension.
Double click to run it (a new icon should show up in the system tray).
Now every time you press Ctrl+F5, the script presses F5 and then Enter. Voila, the confirmation window supressed.
Here's an equivalent of Patrick's answer for Linux users (Ubuntu in my case).
Install autokey (it's in the repos). Add this python script:
import time
keyboard.send_keys("<f5>")
time.sleep(0.5)
keyboard.send_keys("<enter>")
Hook this script to f5 and you will never see the confirm message again. Tested with latest firefox.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\