Jump to content

Paste to the front most application - standalone


Recommended Posts

One of the Alfred workflow outputs is the "copy to clipboard" output. It has an option to "paste to the front most application". I'd love an output feature which only provides the latter functionality, as I'm (as many other people) are using a clipboard manager which shouldn't be crowded with not-copied-on-purpose texts when I just want to output the result of the workflow into the document I'm currently in.

 

Long story short, if there is no other way to paste something out of the workflow to the "front most application", I'd love an workflow output feature to that, without copying the text to the clipboard.

 

Please let me know if there is a better way to do this than I'm currently thinking of. Thanks a lot!

Link to comment
Share on other sites

You can't paste something that isn't on the clipboard.

 

The workaround is to keep a copy of the previous contents of the clipboard and restore that after the paste (this is what apps like TextExpander do), which is simple enough to do with AppleScript instead of Alfred's built-in actions.

 

Most clipboard history managers are smart enough not to keep duplicate entries, but the ordering may change.

Link to comment
Share on other sites

  • 1 year later...

I just hit this issue. I wanted to paste something and then restore the previous clipboard. But Alfred doesn't seem to support that (at least, not without introducing a delay, which I didn't try). If I store the clipboard in a variable, then use Copy To Clipboard w/paste to paste something in the app, and then use a separate Copy To Clipboard action to put the variable back on the clipboard, Alfred runs the second Copy To Clipboard before it pastes in the app. I'd really prefer not to have to fall back to AppleScript just to do this, since it's not all that uncommon of a thing to want.

Link to comment
Share on other sites

In fact, it's not actually obvious to me how to reproduce Alfred's behavior for pasting the current clipboard. If I use `tell application "System Events" to keystroke "v" using command down` then it fails if I have any keys held down when I trigger the workflow (e.g. pressing shift-return). If I instead try to click the menu item "Paste" in the menu "Edit", I get told that Alfred 3 doesn't have assistive access (I don't use auto-expanding snippets so I guess I never hit this problem). So what is Alfred doing in order to paste in the current app?

Link to comment
Share on other sites

20 hours ago, kballard said:

I just hit this issue. I wanted to paste something and then restore the previous clipboard. But Alfred doesn't seem to support that (at least, not without introducing a delay, which I didn't try). If I store the clipboard in a variable, then use Copy To Clipboard w/paste to paste something in the app, and then use a separate Copy To Clipboard action to put the variable back on the clipboard, Alfred runs the second Copy To Clipboard before it pastes in the app. I'd really prefer not to have to fall back to AppleScript just to do this, since it's not all that uncommon of a thing to want.

 

It's nothing to do with Alfred, it's the way OS X works. When you send keypresses to an application (i.e. paste), the system doesn't wait for the application to handle them. Your call returns immediately. So what's happening is that you're restoring the keyboard before the application can act on the paste instruction. You need to put a delay between pasting and restoring the clipboard to give the paste time to complete.

 

That's one of the reasons why it's a terrible way to automate applications.

 

20 hours ago, kballard said:

In fact, it's not actually obvious to me how to reproduce Alfred's behavior for pasting the current clipboard. If I use `tell application "System Events" to keystroke "v" using command down` then it fails if I have any keys held down when I trigger the workflow (e.g. pressing shift-return). If I instead try to click the menu item "Paste" in the menu "Edit", I get told that Alfred 3 doesn't have assistive access (I don't use auto-expanding snippets so I guess I never hit this problem). So what is Alfred doing in order to paste in the current app?

 

I'm 99.5% certain Alfred also simulates ⌘V. I'm also pretty sure Alfred doesn't have the same problem (it breaks if the user is holding other modifier keys) because it uses Carbon, not System Events, to simulate the keypress.

 

This JavaScript function simulates ⌘V via Carbon and should also ignore whatever you've got your fingers on:

ObjC.import('Carbon');

// Simulate CMD+V keypress via Carbon. Unaffected by other modifiers the user may
// be holding down.
function paste() {
  var source = $.CGEventSourceCreate($.kCGEventSourceStateCombinedSessionState);
  
  var pasteCommandDown = $.CGEventCreateKeyboardEvent(source, $.kVK_ANSI_V, true);
  $.CGEventSetFlags(pasteCommandDown, $.kCGEventFlagMaskCommand);
  var pasteCommandUp = $.CGEventCreateKeyboardEvent(source, $.kVK_ANSI_V, false);

  $.CGEventPost($.kCGAnnotatedSessionEventTap, pasteCommandDown);
  $.CGEventPost($.kCGAnnotatedSessionEventTap, pasteCommandUp);
}

 

Edited by deanishe
Link to comment
Share on other sites

17 minutes ago, deanishe said:

 

It's nothing to do with Alfred, it's the way OS X works. When you send keypresses to an application (i.e. paste), the system doesn't wait for the application to handle them. Your call returns immediately. So what's happening is that you're restoring the keyboard before the application can act on the paste instruction. You need to put a delay between pasting and restoring the clipboard to give the paste time to complete.

 

That's one of the reasons why it's a terrible way to automate applications.

 

I just tested, if I use Apple script to explicitly click the "Paste" menu item, then the application pastes before the Apple Script continues, which allows me to immediately set the clipboard again without delay. But of course this does require assistive access. I should probably just grant that to Alfred 3 and use this technique.

 

But you are right, if I keystroke ⌘V with Apple Script, it does not wait, and therefore I would have to introduce a delay in order to set the clipboard.

 

17 minutes ago, deanishe said:

I'm 99.5% certain Alfred also simulates ⌘V. I'm also pretty sure Alfred doesn't have the same problem (it breaks if the user is holding other modifier keys) because it uses Carbon, not System Events, to simulate the keypress.

 

Ah, that would make sense.

 

17 minutes ago, deanishe said:

This JavaScript function simulates ⌘V via Carbon and should also ignore whatever you've got your fingers on:


ObjC.import('Carbon');

// Simulate CMD+V keypress via Carbon. Unaffected by other modifiers the user may
// be holding down.
function paste() {
  var source = $.CGEventSourceCreate($.kCGEventSourceStateCombinedSessionState);
  
  var pasteCommandDown = $.CGEventCreateKeyboardEvent(source, $.kVK_ANSI_V, true);
  $.CGEventSetFlags(pasteCommandDown, $.kCGEventFlagMaskCommand);
  var pasteCommandUp = $.CGEventCreateKeyboardEvent(source, $.kVK_ANSI_V, false);

  $.CGEventPost($.kCGAnnotatedSessionEventTap, pasteCommandDown);
  $.CGEventPost($.kCGAnnotatedSessionEventTap, pasteCommandUp);
}

 

 

Very cool, thanks.

 

I do wish Alfred had a built-in way to "paste to frontmost application" without modifying the clipboard, by using assistive access in order to click the Paste menu item, seeing as that does wait for the application to handle the paste before returning. But at least now I know how to work around this with Apple Script.

Link to comment
Share on other sites

Clicking menu items is an awful way to automate applications that should almost always be avoided if possible.

 

Simulating ⌘V is fragile because the user might change the shortcut. Clicking the Edit > Paste menu is already broken on every system that isn't in English…

Link to comment
Share on other sites

3 minutes ago, deanishe said:

Clicking menu items is an awful way to automate applications that should almost always be avoided if possible.

 

Simulating ⌘V is fragile because the user might change the shortcut. Clicking the Edit > Paste menu is already broken on every system that isn't in English…

 

Good point. I sure wish AppleScript simply had a `paste` command :/

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...