I am trying to set up a script to open a specific page in the notion app. So far I've tried the following:
tell application "Safari"
activate
tell window 1
set current tab to (make new tab with properties {URL:"notion://www.notion.so/Focus-Mode-5eca2183453748d3b5acaa8e7292ef83"})
end tell
end tell
but Safari requires that you give permission to open the app. Is there anyway to get around this? If not, is there anyway to open the page in Notion without having to go through Safari?
It can be even simpler:
I was playing with your solution and found out that even though you can't finde those commands in the dictionary, they still exist:
tell application "Notion"
open location "notion:page:Focus-Mode-5eca2183453748d3b5acaa8e7292ef83"
end tell
I figured out a solution - this was painfully obvious...
tell application "Notion"
open location "notion://www.notion.so/Focus-Mode-5eca2183453748d3b5acaa8e7292ef83"
end tell
Related
(newbie here) I'd to be able to save an applescript file as an app to use to open Safari, I cobbled together this from some old posts I found, it's not exactly what I want but it worked ok, however today it stopped working giving an error "The variable theURL is not defined."
If anyone could help me out with a better script that would work on Monterey I would be really grateful. Also, when I save as an app - should I select 'Stay open after run handler' or 'Run-only'? It just needs to open Safari when it's clicked, I don't need it to really open any particular page. Thanks in advance!
tell application "Safari"
activate
try
tell window 1 to set current tab to make new tab with properties {URL:"https://google.com.au"}
on error
open location theURL
end try
end tell
I cobbled together this from some old posts I found:
tell application "Safari"
activate
try
tell window 1 to set current tab to make new tab with properties {URL:"https://google.com.au"}
on error
open location theURL
end try
end tell
A lot (virtually all) applescripts you see online make overuse of try blocks, which, apart from being completely unnecessary, are problematic in a number of ways, including making debugging more difficult. I'd advise taking out the line try, and everything including and between the lines on error, and end try.
Without those lines, you'll probably get a different error message, which was being masked by the try block. It most likely that window 1 didn't exist, which would be the case if Safari had already been running and didn't have any windows open. It would have then thrown an error, forwarded the script on to the on error block, where open location theURL then, itself, threw an error because theURL hasn't been defined.
I don't need it to really open any particular page
Then all you need is this:
tell application "Safari" to activate
If Safari is already running without any open windows, all this does is bring Safari to the front; it doesn't open a new window for you. If you need to create a new window you can usually do this:
tell application "Safari"
make new document
activate
end tell
However, this will create a new window even if there's already a window open, which might not be what you want. To create a window but only if a window doesn't already exists, you can do this:
tell application "Safari"
if documents = {} then make new document
activate
end tell
I suspect this is the script you will want to use.
Should I select 'Stay open after run handler' or 'Run-only'?
No and no. The first option prevents your app from quitting without explicit instruction to do so, which isn't needed in this case: you simply need your app to open, start Safari, then quit. The last option prevents you from making any edits to the script in the future, which, again, probably isn't what you want.
I'm working on a project using WebKitGTK and I'm having trouble with the WebInspector after having enabled it using the enable-developer-extras property.
I can open it fine, but when I click the close, pop-out into own window, or switch to sidebar buttons they don't do anything. In my application there's literally no way to close WebInspector once you've opened it.
It doesn't appear to be anything I've changed in my code because I remember it working before, but when I check those commits from Git they're now broken as well. At the same time however it does look like something I'm doing because other applications on my computer using WebKitGTK have their WebInspector working perfectly (and yes, I checked out their code).
So my question is: Has anyone faced a similar issue? And does anyone have an idea how it might be fixed?
You're probably hitting this bug. Workaround is to add a dummy call to webkit_web_view_get_inspector somewhere.
I'm opening a custom help file (CHM) using VBA and the api 'HtmlHelp', eg:
hWnd = HtmlHelp(Application.hWndAccessApp, sFile, HH_HELP_CONTEXT, context_id)
The Help file opens, but it's hidden behind the Access window, and although it's icon is displayed in the Taskbar, clicking the icon still does not bring it to the foreground - it remains hidden behind Access.
When I first started testing the Help file (on a Win8.1 machine), it opened correctly in front of the Access window, but now it won't. Does anyone have any suggestions as to what is causing this behaviour?
Some thoughts only - but be careful with the first hint:
Which purpose does the file hh.dat serve?
The hh.dat file stores user-specific information on all the HTMLHelp files (*.CHM) on your system (position, favourite topics, search history, etc.), and can cause a error if it has somehow been corrupted.
Delete or rename the file hh.dat to reset all (!) CHM windows on your system to their default settings.
You should find hh.dat in this directory:
\Documents and Settings\%username%\Application Data\Microsoft\HTML Help
Windows will create a new version of hh.dat when you next open any .chm file.
According to Microsoft's HTML Help API documentation (http://msdn2.microsoft.com/en-us/library/ms644703(VS.85).aspx):
Any help window that you create through the HTML Help API is owned by the calling, or parent, program. This allows the help window to stay on top of its parent, yet not be on top of any other program that has focus.
So the fact that the help window retains focus is actually the standard behaviour.
If you look at a typical HTML Help API call, you'll see that the first parameter specifies the "handle" of the window from which help is called:
HtmlHelp(hwndCaller,"YourHelpFile.chm",HH_HELP_CONTEXT,1001);
If the developer passes "null" rather than the window handle as the first parameter of the call, the help window is no longer owned by the calling program, and so does not retain focus. Here is an example of a modified call:
HtmlHelp(0,"YourHelpFile.chm",HH_HELP_CONTEXT,1001);
There's a drawback to this, though: when called in this way, the help window is no longer bound by the actions of the calling program. So if the user closes or minimises the program, the help window isn't closed or minimised as well.
I see you have hWnd – do you think you can add a code to send the help window to the foreground programmatically?
You can call SetForegroundWindow() to do the job. Someone has solved similar problem already, you just need to port call to SetForegroundWindow() or SetForegroundWindowNative() into the VBA.
EDIT: You report weird behavior that SetForegroundWindow() makes help window to flash only briefly.
Try issuing VBA's AppActivate command – it has helped someone else.
If this problem persists, you can try some workaround like resizing your app and help window to show them side-by-side.
Yes, this happens to people. Yes, I've looked at all the solutions.
This is different.
XCode starts and there is no error message, it just freezes. This is the screen I get:
That's it. No errors. I can't interact with it, I can't close it. The only thing I can do is use Show All Windows. There are five and yes I don't need them all (never did! don't know why I have them) but I can't close any of them. To get rid of it I need to do a hard reset.
I've tried deleting the library file in Finder as this was one of the solutions.
Nope.
Anyone any ideas?
I think it's XCode 6 (the latest) but I can't tell because I can't access the menu.
I ended up scouring Stackoverflow for ways to clear the startup process.
You hold cmd+shift when you start XCode - ONLY from the task bar, this does NOT work if you go into the Applications folder - and it will load blank.
Then you can load your project.
I've confirmed that this is only happening in Lion. I've uncovered what appears to be a bug where you need to focus a window twice in order for Finder to return the correct result over the scripting bridge or AppleScript. This only happens when opening a folder from the desktop or another space.
Here's how to duplicate:
Close, hide or minimize all windows until the desktop is showing.
Open any folder on the desktop, a new finder window will appear. Select any file in that finder window by clicking on it once.
Open your AppleScript Editor and run the following script:
tell application "Finder"
return selection
end tell
The script will return only the path to the folder on the desktop, not the selected file in the finder window.
If you refocus the window, or click on the file again, everything works as expected and the script returns the correct path.
This seems like a bug in Lion. Snow Leopard returns the correct path 100% of the time.
I've tried the following methods with no success:
Using the scripting bridge and https://github.com/davedelong/BetterInfo/blob/master/Finder.h
Using "System Events" apple script to click "Edit"->"Copy"
Using AppleScript to get the current selection from the finder.
All seem to have have the same issue.
Am I missing something obvious or is this truly a problem with Lion?
Wow, I can confirm (at least through applescript) most of what you describe. I was getting an empty list returned, not even the desktop path you mention. I was testing this using a script in the applescript menu. The only way I could get the selection from a fresh Finder window was like this...
tell application "System Events" to activate
tell application "Finder"
activate
set a to (get selection) as text
display dialog a
end tell