The solution here is to move the process order such that the visual change (The un-highlighting of the dimension function, or any other relevant function for that matter) to the front of the que such that the user sees an immediate change in the state of the program, even though the program may take a couple of seconds to catch up. The user then gets into the false impression that spamming the escape button is the way to go. The issue from a UI standpoint is there is nothing to tell the user there is anything happening and so the assumption is made nothing has happened and therefore it requires another press of the escape button which it doesn't but which seems to do the trick.

The system needs to be optimised rather than reduced. This seems to be up to a 2 second delay and varies arbitrarily. This led me to falsely believe it was related to the number of presses of the escape button rather than just waiting for the system to catch up to the user. There is an arbitrary delay between the pressing of the escape button and it escaping. I have just done some stress testing of the system to work out wat's going on. Sometimes you may need to use the ALT key to move into the menus. Usually either tabs and/or arrow-keys will suffice. I use both Autocad and Inventor but was referring to Inventor with this post in general as it is the software I currently use the most. To get the VBS code to work how you want, youll need to learn how to navigate around Adobe Air by keyboard. I wouldn't have made the association but as it is made by the same group I felt the comparison was relatable. I was referring to autocad there as an example in the different methodologies of tracking what constitutes a 'change' in the list.

On screen keyboard autoclick