I'm trying to create a conditional delete in Curio.
There are three kinds of objects in Curio that are important to this macro:
Idea Spaces (pages)
Assets (images, videos, files, etc)
Text
When I press the Delete Key in Curio, it has different behaviors depending on what is highlighted:
Idea Spaces - open dialogue box with button "Delete to Trash"
Assets - open dialogue box with button "Delete from Project"
Text - deletes the text
I successfully built a macro that allows me to delete text, but if an asset is selected, a second press of the Delete Key will click the "Delete from Project" button and delete the asset:
If the "Delete from Project" button doesn't exist, it passes the Delete Key to Curio, and that either deletes a text selection or if an asset is selected, it provokes the dialogue box with the "Delete from Project" button to appear.
Okay, here's where the fun begins -- I wanted to add a function for deleting an Idea Space requiring three deletes instead of two. Deleting a whole page of material should have a slightly higher hurdle.
I got this far, but it doesn't work. Also, I have the nagging feeling that there's a much more elegant way to build this. I didn't use a Switch because it doesn't have a Button Condition, and I thought the extra steps would outweigh the time saved over using If/Thens.
I thought all I'd need to do is add a User Input and a couple more If/Thens, but I haven't been able to get it to work. It gets as far as opening the User Input, but then I can't get it to see the second press of the Delete Key to close the Input Box and move on.
You can't use the Delete key as a button key shortcut, so the dialog will remain until you click a button or hit Return (default for "Do It") or ⌘. to "Cancel".
If you do want to continue this way you could create another macro, "Override Delete with Return", that has a hotkey trigger of ⌫, a single action of "Type a Keystroke -- Return", and that is disabled by default. Then add an "Enable Macro" action immediately before your "Prompt..." action to turn on the override and a "Disable Macro" immediately after to turn if off again.
One thing to remember is that as well as this allowing "Delete" to click the default button, hitting "Return" will also click the button. If you really want to do this, it might be safer to have the sub macro type some other key that you are unlikely to press (say "w") and name your default button like this (the w after the / won't show on the button but is set as its default key).
This could all go horribly wrong if things got out of step and the sub macro was somehow left in an enabled state as every hit of Delete would be typing a w... so, I added in an extra "disable macro" action into the key press Macro itself so that at least that would only happen once.
As the default behaviour of the Prompt is hitting Return to confirm I would say changing your text to "Hit RETURN if you really want to delete this Idea Space" would be simpler and safer (and also expected behaviour).
Thanks for your suggestions. I finally got this sorted out.
I ran into a few unexpected problems:
(1) KM can't see the buttons on its own dialogue boxes, so
(2) KM can't evaluate when the boxes exist based on evaluating the buttons.
(3) I was using the status of a menu item (WebView) to determine whether the selected item was an Idea Space (because when an Idea Space was selected, WebView was disabled.) However, the WebView menu would also become disabled when Curio put up its dialogue box, and that led to some false branching.
I solved it like so:
(1 & 2) I made a Global Variable to store the ON and OFF state of the KM Dialogue Box, so KM would know whether the box was available. I used a straight return to close the box.
(3) I put a check for the non-asset Delete button at the top of the macro to head off the false positive caused by the Curio dialogue box being up.
There are other ways of doing this (for example, you could track "Last Engine Window ID" in a Global), but you can see if an "Alert" window is showing with:
...and Local_winExists will be "true" if a KM Alert window is present, "false" otherwise.
But I'm with @Zabobon -- it's generally not a good idea to subvert "normal" dialog operations like this. You can use "Return" to continue, the "Return" key is right next to "Delete", so doing things "normally" doesn't cost you much.
If the only reason you're throwing the dialog is "I've pressed Delete once and want to catch a second press" then you could revisit your design. So instead of running the macro once every time you press the Delete key you might instead:
Run it once when triggered
In the "CONFIRMATION BOX" condition, instead of Opening the Alert box and exiting you do a "Pause Until..." the Delete key is pressed, then pass the Delete action and exit
Note that you will have to use a "Semaphore Lock", set to timeout after 1/100th of a second, to prevent the macro from re-triggering when press the Delete key the second time, and you might need a small pause to separate the trigger key stroke from the "Continue" one.
Here's an example you can run while TextEdit or similar is frontmost -- triggered by a bare 1 keystroke it will wait until you either press 1 again then it'll type the character, or you press . to cancel.
