A little stumped. I've got several macros that take the selected files from finder, and then use them to do various things. I'd like to add the ability to also drag multiple files onto the macro via the dragged file trigger and have it run essentially the same way. All my macros/subroutines work from a list of files, so ideally i'd be able to just generate a list of dragged files from the trigger and move on with whatever i'm doing.
I set up the trigger, pulled the %TriggerValue% and %TriggerBase% to determine how the macro was launched, and that all works great. The issue i'm coming up against, is that the dragged file trigger, as it is intended to do, triggers the macro one time per file dragged onto the macro.
I tried using a semaphore lock, and that works, until the macro finishes, then it just runs it again!
First question -- do you need the extra fuss caused by dealing with drag'n'drop? Could you not select the files in the Finder then simply click your palette button, starting the macro with a "For Each Item...Finder's Selection Collection" action? Not only is it less work for you to code, clicking is usually easier for the user than drag'n'dropping to a small target.
But if you do want drag'n'drop, one approach would be gather the individual trigger events into a collection then pass that collection on for processing. Here's an example that splits this into three macros, one for each stage.
"Trigger Macro" uses a semaphore lock so it processes the dropped files sequentially rather than spawning multiple concurrent instances. It checks to see if "Collecting Macro" is running, spawns it if it isn't, then appends its trigger to a global.
"Collecting Macro" sets its "running" flag, then starts a loop where it gets the character count of the global, pauses, then checks the "old" character count against the new -- when those are equal, "Trigger Macro" has stopped writing to the global -- ie, all files have been added -- so "Collecting" can trigger "Processing Macro" then unset its own "running" flag and exit.
"Processing Macro" grabs a local copy of the global, then deletes the global's contents so the global is ready for the next drag'n'drop. All it then does in this example is a Display Text for each item in the collection then a final Display Text showing the complete collection, so you can easily see what's been passed to it and how you can process the paths in later actions.
There's probably a better way -- I kept hoping someone would post something! -- but this is quite easy to grok and adapt to your own needs.
Fair points. I certainly don't NEED it. I've already build my macros around getting the finder selection and they work very well, and are my preferred method of triggering. I share them with my co-workers, and a lot of them are "used to" using compressor droplets, or other automator actions that use the drag and drop functionality, so I thought it would be nice to add the drag and drop functionality to the macros.
I figured this might have to be broken up into multiple macros, but I couldn't get my tired brain around it yesterday I'll give this a shot and see how it works. Thank you!
I'm sure you can merge the second and third, but separating them makes the different functions more obvious for the example.
And, thinking ahead, you might be able re-use at least the second macro by passing parameters -- I don't know if you can "attach" the same macro to multiple palette buttons and pass along which button was used, but you could use indirection to reference different globals for different purposes and parametise the "Execute macro" action in the second to call different "processing" macros (or use one monster processor with different branches for different functions).
Yeah, looking at how to potentially integrate this with my current set of macros is a little overwhelming. Gonna mess with it this afternoon a bit.
Edit: Just messed around a little bit, and implementing this in a way that would keep things simple, and allow for a single trigger macro for either drag and drop or clicking to get the finder selection just isn't worth it for the little bit of extra functionality. I really appreciate you figuring it out though!