I *think* I understand what is going on.... And I think it is a timing issue, and it just so happens that the timing has changed (enough to make a difference) between 2.15 ans 2.16/2.16.1 (2.16 is probably slightly faster and thus suffers more - the problem *could* still exist in 2.15 as far as I can see, I think its just luck that it doesn't (and I dont like that!))...
When sending shifted keys, the simkey expression is parsed, and it checks if shift is already pressed, if it is, it does not simulate the shift.
The problem is, that in the time between parsing, and actually sending, shift has been released again, so 9 or 0 are sent instead on ( or ).
That's why on my machine it behaves differently (I did manage to reproduce on the wheel once or twice in a sequence of 10(ish).
Moving the check if SHIFT is already pressed, closer to the time its sent might help, but still there is a chance if could go wrong, if the keyboard buffer injection is slow (e.g. if the CPU is busy), the problem could occur - actually I'm not so sure there can be a perfect/guaranteed solution using the SendInput API
Does it always produce the correct result on the first scroll, and then subsequently random, sometimes working, sometimes not, or was it even wrong on the first scroll (which might invalidate my theory!)???
Thanks,
Phil
EDIT: I have tried removing the check if the extended key (shift, ctrl, alt etc.) is already down and sending it anyway. This works much better (and will be less resource intensive too!). The only time it could go wrong is if you are actively pressing/releasing the key on the real keyboard at the same time... I guess that's unlikely to happen (although there must be a reason I went down this route in the first place lol). I guess we shall have to see how it plays out, I will include this change when I start the 2.17 beta run (and try and remember to let you know so you can test it for me
).
