kodiak Posted August 10, 2018 Share Posted August 10, 2018 Hi Everyone, I'm building a small workflow that should run a .scpt file with keyword. I would really like to leave the file as is so I'll be able to edit it using Apple's Script Editor or Script Debugger, as they offer lots of benefits directly aimed for writing AppleScripts. Here are my considerations: 1. Using the Run Script action with the External Script option won't work. 2. Running the script within Alfred or embedding it in a shell script (and either running it in Alfred or as an external script), and I won't be able to use Script Editor or Script Debugger. 3. Choosing to run AppleScripts in Alfred's preferences (instead of editing them), and then setting the workflow to simply open a file means relying on intricate paths. Ideally, the AppleScripts would be called from the workflow's folder with as minimal paths as possible (./). What should I do? Thanks! Link to comment
vitor Posted August 10, 2018 Share Posted August 10, 2018 Put your Script.scpt (or whatever) inside the Workflow’s directory. Make a Run Script with /bin/bash as the Language. Make it osascript ./Script.scpt. kodiak 1 Link to comment
kodiak Posted August 10, 2018 Author Share Posted August 10, 2018 Brilliant, thank you @vitor! And while we're at it, how do I pass an input from the user, as an argument, beginning in Alfred's bar, through that shell script and all the way to the AppleScript? Thanks again. Link to comment
vitor Posted August 10, 2018 Share Posted August 10, 2018 The argument from Alfred will come from whatever Keyword you choose. To pass it to the script, use osascript ./Script.scp "${1}". kodiak and syv 1 1 Link to comment
kodiak Posted August 11, 2018 Author Share Posted August 11, 2018 Thanks! And in the script itself, should I do something like the following? on run(q) end run Where q is the argument. Link to comment
vitor Posted August 11, 2018 Share Posted August 11, 2018 5 hours ago, kodiak said: Thanks! And in the script itself, should I do something like the following? on run(q) end run Where q is the argument. Yes. kodiak 1 Link to comment
kodiak Posted August 13, 2018 Author Share Posted August 13, 2018 (edited) Thank you very! I have been implementing your suggestion with great success up until this script: set originalMouseLocation to AST mouse point location tell application "System Events" to tell process "Dropbox" set dropboxLocation to position of menu bar item 1 of menu bar 2 end tell set dropboxLocationX to item 1 of dropboxLocation set dropboxLocationY to item 2 of dropboxLocation AST click at {dropboxLocationX, dropboxLocationY} holding modifier key ast option key AST set mouse point location originalMouseLocation Whether run within Alfred or by the way of your suggestion, the script behaves weirdly: 1. The last line is not executed (returning the pointer to its original location). 2. For some odd reason, running this script triggers a Dropbox synchronization for .scpt file, as if something has changed within the script. Running the script through Script Debugger or Script Editor works perfectly. Help would be very appreciated! Thanks! Edited August 13, 2018 by kodiak Link to comment
vitor Posted August 13, 2018 Share Posted August 13, 2018 When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. There are multiple places where your code or Workflow setup may be going wrong. Also GUI scripting is notoriously finicky, and you shouldn’t do more than what you absolutely need. There are ways in AppleScript to activate menus without moving the mouse to click them (not sure they support alternative menus like in this case, though). Link to comment
deanishe Posted August 13, 2018 Share Posted August 13, 2018 33 minutes ago, kodiak said: For some odd reason, running this script triggers a Dropbox synchronization for .scpt file, as if something has changed within the script. I've noticed this. macOS appears to re-compile the script files (or otherwise do something to them) when it runs them. Link to comment
kodiak Posted August 14, 2018 Author Share Posted August 14, 2018 (edited) 23 hours ago, vitor said: When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. There are multiple places where your code or Workflow setup may be going wrong. Also GUI scripting is notoriously finicky, and you shouldn’t do more than what you absolutely need. There are ways in AppleScript to activate menus without moving the mouse to click them (not sure they support alternative menus like in this case, though). 1. You're correct, my bad. Here's a link to the workflow (sorry for the mess, it's a work in progress). https://www.dropbox.com/s/x0d4fpnia327oot/Menu Bar Icons.alfredworkflow?dl=0 2. I know, I don't like to rely on GUI scripting and even more so on GUI scripting that revolves moving the pointer around, but in cases such as this (where I need to option-click something), there're no other options. 23 hours ago, deanishe said: I've noticed this. macOS appears to re-compile the script files (or otherwise do something to them) when it runs them. 3. I see, if so, then why it doesn't happen in all scripts? 4. So the only solution to this is to run the scripts within Alfred? Thanks! Edited August 14, 2018 by kodiak Link to comment
vitor Posted August 14, 2018 Share Posted August 14, 2018 1 hour ago, kodiak said: You're correct, my bad. Here's a link to the workflow (sorry for the mess, it's a work in progress). https://www.dropbox.com/s/x0d4fpnia327oot/Menu Bar Icons.alfredworkflow?dl=0 The regular dropbox action works fine for me. The ⌥ version doesn’t: [ERROR: action.script] osascript: ./dropbox-option-down.scpt: No such file or directory. You haven’t included the script. 1 hour ago, kodiak said: I see, if so, then why it doesn't happen in all scripts? Because most scripting languages interpret the script instead of compiling it. kodiak 1 Link to comment
deanishe Posted August 14, 2018 Share Posted August 14, 2018 5 hours ago, kodiak said: 3. I see, if so, then why it doesn't happen in all scripts? It does, as far as I can tell. 5 hours ago, kodiak said: 4. So the only solution to this is to run the scripts within Alfred? No, Alfred runs them the normal way. And it's hardly a big issue anyway. If you don't want the scripts to change, save them as .applescript (text) files instead of compiled scripts. kodiak 1 Link to comment
kodiak Posted August 16, 2018 Author Share Posted August 16, 2018 On 8/14/2018 at 2:16 PM, vitor said: The regular dropbox action works fine for me. The ⌥ version doesn’t: [ERROR: action.script] osascript: ./dropbox-option-down.scpt: No such file or directory. You haven’t included the script. Oops, my bad. I thought all workflow objects are included upon exporting it. Below is a link to the (revised) workflow file itself. https://www.dropbox.com/s/4pmsrhnbv7l8wgd/Status Bar Icons.alfredworkflow?dl=0 Link to comment
vitor Posted August 16, 2018 Share Posted August 16, 2018 2 hours ago, kodiak said: Oops, my bad. I thought all workflow objects are included upon exporting it They are. Not sure what happened there. I get the following error: [ERROR: action.script] ./dropbox-option-down.scpt: execution error: «script» doesn’t understand the “«event ASTgetlo»” message. (-1708). The error is also reproducible when running the script from the Script Editor. Link to comment
CJK Posted August 17, 2018 Share Posted August 17, 2018 For the benefit of the OP, @kodiak, «event ASTgetlo» is the raw syntax code for AST mouse point location. The error reported by @vitor relates to the commands from your scripting addition, which the script doesn't understand. If you're trying to export a workflow, it won't be able to run on any system without the scripting addition included as part of the exported package. That's one reason why using scripting additions is disadvantageous. I can see you're trying to access the Dropbox menubar pop-up menu, which requires a modifier key to be depressed whilst clicking - something that can't be done conventionally with System Events. However, if you consider which functions you want to access from that pop-up menu, I believe all of them are accessible through other means, namely the standard left-click pop-up pane, which has a preferences (cogwheel) button and a few other buttons that provide those options. That will be regularly scriptable using System Events, if you really must go down that avenue. Link to comment
kodiak Posted August 18, 2018 Author Share Posted August 18, 2018 On 8/16/2018 at 1:36 PM, vitor said: They are. Not sure what happened there. I get the following error: [ERROR: action.script] ./dropbox-option-down.scpt: execution error: «script» doesn’t understand the “«event ASTgetlo»” message. (-1708). The error is also reproducible when running the script from the Script Editor. Sorry about that! The workflow has a dependency which I forgot to mention, it's the AppleScript toolbox: https://astoolbox.wordpress.com. 19 hours ago, CJK said: For the benefit of the OP, @kodiak, «event ASTgetlo» is the raw syntax code for AST mouse point location. The error reported by @vitor relates to the commands from your scripting addition, which the script doesn't understand. If you're trying to export a workflow, it won't be able to run on any system without the scripting addition included as part of the exported package. That's one reason why using scripting additions is disadvantageous. You're totally right, but since I'm a complete workflow novice I had no idea how to include a dependency within a workflow, and install it upon the installation of the workflow itself (in this case, a simple copy to /Library/ScriptingAdditions/. And since I have the use mouse movement for this script to work, this addition has to be included. Nevertheless, I still can't explain why running the workflow within Alfred fails (unless I introduce delay into the script). 19 hours ago, CJK said: I can see you're trying to access the Dropbox menubar pop-up menu, which requires a modifier key to be depressed whilst clicking - something that can't be done conventionally with System Events. However, if you consider which functions you want to access from that pop-up menu, I believe all of them are accessible through other means, namely the standard left-click pop-up pane, which has a preferences (cogwheel) button and a few other buttons that provide those options. That will be regularly scriptable using System Events, if you really must go down that avenue. Actually, I have been considering this approach and indeed it does look like a better solution. I still wish however to resolve the current script's issues, just for the sake of the challenge P. S. - How do I insert those inline code blocks? Thanks again! Link to comment
CJK Posted August 18, 2018 Share Posted August 18, 2018 (edited) [background=#eee][font=courier,monospace]sample inline code typeface[/font][/background] should render as sample inline code typeface. This font is Menlo Edited August 18, 2018 by CJK Link to comment
vitor Posted August 18, 2018 Share Posted August 18, 2018 1 hour ago, kodiak said: How do I insert those inline code blocks? They’re not code blocks. Rather, it’s a text style change. I make them (and other text changes) via Markdown converted to BBCode with MarkdownTransform. CJK 1 Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now