I have a variation on this one that I think would solve a problem I'm having...
I send a sequence of keystrokes, including several that open a menu, arrow down a couple of items, arrow right, arrow down a couple of items (essentially navigating through a drop-down menu). All of this is required because the function I want executed has no short-cut key in the app in question.
Using StrokeIt! this sequence only works about 20% of the time, i.e. I have to repeat it 4-5 times before the proper action finally occurs. I know StrokeIt! recognizes the gesture because the first keystroke in the sequence *is* an application hotkey that causes a visible change in the display, while the remaining keystroke sequence(s) should result in subsequent changes in the display that *don't* occur.
I think the answer here would be to put delays *between* the keystrokes; preferably in a manner to the way we used to add pauses to dialing sequences in modem dial strings: Have a special [pause_function] that can be included in the keystroke sequence where any delay is needed. It could either support a parameter for the number of milliseconds (e.g. [DELAY:50] or [BEGIN_PAUSE]50[END_PAUSE] or just have a 10 ms delay for each and we could put multiple copies for longer delays (e.g. [PAUSE][PAUSE][PAUSE] = 30ms delay).