Describe the bug
The action "Ask for input, save to variable" no longer puts the cursor in the ask for input dialog. One must scroll the mouse to the BTT input dialog and click in it to give a response
Device information:
thanks for reporting! I‘ll fix that in a few minutes.
//fixed it but release will take until tomorrow
Installed alpha ver with fix just now. Very unstable.
Input dialog works now, but was displayed before "Show HUD" action (see screen shot).
Then, no further processing was successful. Had to hard reset my mac twice because of spinning beach ball creating an all-out, blocking scenario. Script had performed flawlessly for several months prior.
that's weird, it seems to work great here :-/ The only change I did was to make the BTT process frontmost if the "Ask for Input" is shown.
What exactly does your action sequence do? Maybe I can try here.
I also can't see anything that would be able to cause a beachball there.HUD's are always asynchronous, the next action doesn't wait until the HUD is hidden so it's normal that the ask input field would show before or at the same time as the HUD.
//edit: ah maybe one question, how are you triggering that action sequence?
Reverted to 4.707 and I'm back in business
I trigger using ⌥-shift-` (backward apostrophe)
The action sequence asks for an A, D, or B and stores in ACEUpdateChoice
It uses selected_text which stores a Sheets row number that allows for moving around the spreadsheet using ^G (goto cell) actions (ex. V(BTT)@variable:selected_text(BTT))
It then copies values from Google sheets cells that I've ^G'd to in conjunction with CopyLess2
It opens a new web page that's a web-based form and pastes values from CopyLess2 based on whether I've chosen A, D, or B
Saves the form, cmd-W's out of the page back to the Google sheet and ^g's to the next row
With the latest BTT version, it prompts me for the ACEUpdateChoice, I answer with a "D" and all goes haywire
I see the beach ball and flashes of the Chrome menu bar items darkening and lightening and then it's a denial-of-service that I have to hard reset to get out of
I think I might know what's causing this, although I can't reproduce here. With the change the "Ask for input" view took the focus from the previously active view and due to that the actions following afterwards might target the wrong window.
Could you check whether 4.715 solves this for you? (uploading now, available in 10 min)
4.715 fixed it!
Dialogue box has cursor in it, I answer, and script performs as expected.
