Call 1p (1Password 1Click Bookmarks integration) via external trigger

[PaulF]

I would like to call the 1Password 1Click Bookmarks integration (1p keyword in my case) from AppleScript. I do this to call other workflows using an External Trigger. Is this possible with the 1p integration?

 

For context, I regularly launch a website and open a specific group in DEVONthink and a specific sheet in Numbers as part of a finance workflow. I have used an external trigger to have the Numbers workflow call the DEVONthink workflow with the same argument taken from the Numbers workflow script filter. I would like to also fire 1p from that same AppleScript.

[PaulF]

I think that I have solved my own problem with help from an old post on this forum.

Calling a Workflow from another Workflow - Workflow Help & Questions - Alfred App Community Forum

 

To trigger "1p" from my AppleScript I use the "search" method instead of the "runTrigger" method.

 

If I have a variable "sheetName" in my AppleScript this becomes:

 

tell application id "com.runningwithcrayons.Alfred" to search "1p " & sheetName
delay 0.2
	tell application "System Events" to keystroke return

 

Note the space after 1p.

 

When I added two of these calls in my script I found that I needed a short delay between the calls to get everything to "fire" properly.

 

tell application id "com.runningwithcrayons.Alfred" to search "1p " & sheetName
delay 0.2
	tell application "System Events" to keystroke return
delay 0.2
tell application id "com.runningwithcrayons.Alfred" to search "1p " & sheetName
delay 0.2
	tell application "System Events" to keystroke return

 

I don't really understand the need for the delays but without them the subsequent code doesn't run.

 

[vitor]

18 hours ago, PaulF said:

I don't really understand the need for the delays

What you’re doing is referred to as “GUI Automation”. Instead of having a script go through a set of steps, only advancing when the previous returns, GUI Automation fires the command but has no way to check its result.

 

That means if an event triggers before the previous one is done, you will be sending the right command to the wrong place. The delays are necessary to ensure everything is in place.

 

They won’t be consistent. Sometimes a shorter delay would have sufficed while others it won’t be enough (e.g. you computer is under load, thus slower). Which is why GUI Automation is generally used as a last resort.

Edited May 16, 2021 by vitor

[PaulF]

Thanks @vitor for your explanation.

 

Is there a better way to call a script filter from within another workflow and append the return to continue the processing in that other workflow.

 

The external trigger is a "fire and forget" mechanism as noted by @deanishe in another post.

[vitor]

42 minutes ago, PaulF said:

Is there a better way to call a script filter from within another workflow and append the return to continue the processing in that other workflow.

 

No. Once you move to the second Workflow you’re in a different place; the first won’t get any information back unless you specifically add the triggers to send information back (which isn’t really a continuation, it’s a new call).