As long as 10, 210, 10 works, you should be ok - the main idea is to make sure that everything works swift enough not to make you wait too long for the whole sequence to complete successfully (and at the same time not so fast that a command doesn't have enough time to complete and gets skipped over; and this applies to some Autohotkey macros and batch files etc. also) .
The final test run on 10, 201, 10 works. The attempt at 10, 200, 10 gives NP. Why in the world does that context menu have to be onscreen for one more ms?
I have tried to find another way to shift the focus in the context menu to the bottom line, but UP is the most economical. Ctrl + UP works, as does Dn Dn Dn Dn Dn Dn Dn (7 lines in menu; first Down just focuses on top line). Up places the focus on the bottom line without first having to focus on the top line and then move it.
Once more, das, thank you. If I could give you more reps, I would.
Dan
Interestingly enough, the slightly older computer, which is slower, but just barely (we're talking milliseconds here, after all), requires 230 ms where the main machine works with 201. Tried 201 NP, 210 NP, 220 NP, 230 Good. Hey, you never know.
On my System, because I use the "Overflow Area" for extra icons in the System Tray, the script 'selects' the chevron and then activates the "TaskBar Settings", and the script works even if I remove all the Sleep values. But I would still use generous Sleep values, as that way I know that the script will work because you never know what else might be going on behind the scenes, performance-wise.
We all make interesting individual choices when we configure our machines. I don't like the chevron, so I make all of my systray icons unhidden when they're active. And I keep that notification icon to the left of the clock, where I'll notice it when it turns white. Unless I have something running that uses the systray, mine is barebones. The really faint one on the far left is Malwarebytes. My choice of accent colour for the taskbar makes their icon almost invisible.
@das10
It occurred to me this morning that since the Notification panel is normally triggered by the Notification icon, and I keep the Notification icon out of the corner and to the left of the clock, maybe it's the proximity of the NP icon that's causing problems with the PS1 code.
Another sudden epiphany (a day or two ago, when running the code again produced the NP, instead of the desired result): many (if not all) of the good results during the intensive testing routine were produced after the code had triggered the NP and I had closed the NP and used another choice of command from the seven-line context menu. This made those successful runs second runs. You'll recall that the initial testing (See posts #'s 6 and 8 above) came back this way: "Your script works perfectly for me the second time I use it."
Gonna work on it with the N icon back in the corner, just to see whether that re-positioning contributed to the misfires.
[edit -- 10 minutes later]
Nope. Position of N icon doesn't affect results, neither good ones nor misfires. I'll stay with the higher wait times, No big deal. Thanks again.
I have found from past experience that it is always better not to pare down sleep times in keyboard macros too much, otherwise, as you have noted with your experiments, the sequence of commands cannot be guaranteed at all times, or every single time.
It hasn't missed yet (@ 5 first tries on each computer) at 50, 300, 50, so I think I'll let 'er rest now.
Quote
