I set up a keyboard mapping in Chrome that changes the action of the Enter key to Cmd+Enter. The condition for this mapping is that the focused element's details must contain "AXRoleDescription: "Text Box"".
This effectively allows the Enter key in the Chrome address bar to open links in a new tab, and it works perfectly without any issues. However, it has an irreversible effect on other areas of the Chrome interface; specifically, the Enter key becomes completely unresponsive in any location other than the address bar. I have confirmed that the mapping only triggers when the mouse is focused on the address bar.
In other words, when my trigger condition is not met, the Enter key becomes ineffective directly. I am unsure if this is a bug.
this is normal, to workaround it you need to record the enter key again and set the inverse condition, then make it send the enter key
Example:
I added an entry to the self-mapping of 'enter' with the condition being NOT (focused_element_details == " AXRoleDescription: "Text Box"").
This adjustment has worked.
However, I'm curious about the underlying logic of our software. When condition 'a' is met, it triggers 'b'. In general, when 'a' is not met, 'b' should not be triggered automatically, while all other original functionalities remain intact, right?
I haven't set any reverse mappings for other operations, such as mouse button mappings, and there haven’t been any issues so far.
When do we actually need to set up reverse judgments? It seems that our underlying trigger logic can sometimes be quite puzzling.
Advanced Trigger Conditions (in contrast to Conditional Acitvation Groups) are only evaluated (for performance reasons) once the trigger has been triggered. In case of keyboard shortcuts this means the shortcut has already been caught by BTT and will not reach the system anymore. After the shortcut has been caught BTT evaluates the condition and only executes the assigned actions if the condition is true
Sure! Here's the translation of your question:
Question to Andreas:
I've noticed a difference in behavior between keyboard and mouse events in BTT. When I map a mouse button to a specific action with a condition, and the condition is not met, the original mouse button function is still triggered. However, when I map the Enter key and the condition is not met, the original Enter functionality is completely blocked and doesn't work.
Why is this happening? It seems like the key event is being completely swallowed by BTT when the condition is not satisfied. I understand that mouse events pass through by default, but why isn't the same happening for keyboard events, like Enter?
Wouldn't it make sense for the original behavior (the default Enter action) to still be triggered when the condition is not met, similar to how mouse events work?
Let me know if you'd like to tweak it further!
yes, keyboard events are much more complex. For mouse events I have added some workaround that makes a pass through possible, I can't do this for keyboard events.
Thank you for your response. I will make sure to pay attention to adding inverse conditions when using the keyboard in the future. However, some inverse conditions can be quite challenging to implement.
For example, the condition states:
Trigger when a contains the text "000" and b contains the text "000."
Our inverse condition would be: a does not contain the text "000" or b does not contain the text "000." However, I noticed that BTT does not offer an option for "a does not contain the text '000.'"
