I have just observed a strange behaviour in the auto-type feature and I think it is a bug. Suppose we have an entry with a default sequence such as this one:
*why is this program typing so slowly?{ENTER}{DELAY=200}*
If it is invoked you will see each and every letter typed as the 200 delay will be inserted before (or after - I am not sure) every of the symbols preceding it. If you remove the {DELAY}, the rest is typed normally.
I was not able to conclude if this affects the entry with TCATO enabled - there is a slight difference when the {DELAY} is at the beginning, at the end and missing, but it still goes too fast to be able to follow.
This also brings up another issue:
Auto-type is unstoppable once it has started!
I have a pretty long sequence in one of my entries and I inserted a {DELAY=5000}. When I invoked it - OMG!!!
The combination of these two can be disastrous especially if it happens to a less experienced user - basically the system becomes unusable until you kill KeePass, which in the mean time has become non-responsive (even Exit from the menu did not stop it).
It would be sufficient if switching the focus from one window/application to another is used as a trigger to cancel the auto-type in progress. Starting it in one window and continuing it in other(s) is useless anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ctrl Alt Del stops the auto typing only for as long as the Windows Security dialogue is displayed. If you close it the typing continues.
What is the point to have a delay that affects the whole sequence? In ver. 2.08 and back to 2.06 (the first one I ever used) the delay was in effect only where it was inserted and was much more useful. May be you should implement a new placeholder for this purpose - something like {SPEED=xxx}.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, I see.
Thank you!
Please excuse me for the false alarm.
And what about stopping the typing? It really does not stop after Ctrl Alt Del, though it looks like it does. Actually after dismissing the Windows Security window the focus is "nowhere" so nothing is really typed, but if you focus a window it continues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KeePass must continue auto-typing when windows are switched, otherwise you for example couldn't start a browser, navigate to a website and login automatically using auto-type. Multi-step processes couldn't be automated anymore (for example the {NEWPASSWORD} placeholder can be used to change passwords and target applications often ask for a password confirmation, possibly in a second dialog).
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> KeePass must continue auto-typing when
> windows are switched
Yes, you have a point. Then may be it is a good idea to implement an optional (and probably disabled by default) global hot key for cancelling the current auto-type in progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just observed a strange behaviour in the auto-type feature and I think it is a bug. Suppose we have an entry with a default sequence such as this one:
*why is this program typing so slowly?{ENTER}{DELAY=200}*
If it is invoked you will see each and every letter typed as the 200 delay will be inserted before (or after - I am not sure) every of the symbols preceding it. If you remove the {DELAY}, the rest is typed normally.
I was not able to conclude if this affects the entry with TCATO enabled - there is a slight difference when the {DELAY} is at the beginning, at the end and missing, but it still goes too fast to be able to follow.
This also brings up another issue:
Auto-type is unstoppable once it has started!
I have a pretty long sequence in one of my entries and I inserted a {DELAY=5000}. When I invoked it - OMG!!!
The combination of these two can be disastrous especially if it happens to a less experienced user - basically the system becomes unusable until you kill KeePass, which in the mean time has become non-responsive (even Exit from the menu did not stop it).
It would be sufficient if switching the focus from one window/application to another is used as a trigger to cancel the auto-type in progress. Starting it in one window and continuing it in other(s) is useless anyway.
The delay keyword affect the whole Auto-Type sequence.
To stop Auto-Type try Ctrl Alt Del.
cheers, Paul
Ctrl Alt Del stops the auto typing only for as long as the Windows Security dialogue is displayed. If you close it the typing continues.
What is the point to have a delay that affects the whole sequence? In ver. 2.08 and back to 2.06 (the first one I ever used) the delay was in effect only where it was inserted and was much more useful. May be you should implement a new placeholder for this purpose - something like {SPEED=xxx}.
The placeholder you mean is {DELAY XX}.
{DELAY XX} delays XX milliseconds once, at the current position.
{DELAY=XX} sets the default delay to XX milliseconds for all standard keypresses in this sequence.
This is documented here: .
http://keepass.info/help/base/autotype.html#autoseq
Oh, I see.
Thank you!
Please excuse me for the false alarm.
And what about stopping the typing? It really does not stop after Ctrl Alt Del, though it looks like it does. Actually after dismissing the Windows Security window the focus is "nowhere" so nothing is really typed, but if you focus a window it continues.
KeePass must continue auto-typing when windows are switched, otherwise you for example couldn't start a browser, navigate to a website and login automatically using auto-type. Multi-step processes couldn't be automated anymore (for example the {NEWPASSWORD} placeholder can be used to change passwords and target applications often ask for a password confirmation, possibly in a second dialog).
Best regards,
Dominik
> KeePass must continue auto-typing when
> windows are switched
Yes, you have a point. Then may be it is a good idea to implement an optional (and probably disabled by default) global hot key for cancelling the current auto-type in progress.