sometimes when i use the autotype keepass misses the first letter,,, or sometimes the first letter comes out but is in lowercase when it should be upper case...
what is causing this problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is an unusual error.
Do you have other keyboard software loaded? Do you use an unusual keyboard?
Can you auto-type into Notepad to check that it is not your keyboard?
What software are you using when auto-type fails?
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Paul,
I have exactly the same problem. After your suggestion I checked, and the unusual thing I have is a Logitech keyboard, with Logitech software (SetPoint) running. If I close SetPoint, the problem dissapears. If I open back SetPoint, I have the behaviour again, no first letter.
Another thing I think I have noticed is that if I modify something on the entry of KeePass and then autotype, even with SetPoint working it will work. After the save, will stop working with the first letter behavior.
Best regards,
Julio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which browser do you use?
For Maxthon such kind of behaviour is known.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-08-16
i use IE, gaim, thunderbird, norton, keepass are the only things loaded. my keyboard is normal, no software for it... it USUALLY works fine, just every once in a while it wont work (until i exit and reload keepass i believe)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have also found the same issue in IE7 only. Auto-typing to Opera 9.02 and Firefox 2.0 seems consistently okay. Results in Notepad are also reliable. (Keyboard is the internal keyboard of a Dell Inspiron 9400 laptop with US layout and no special keyboard software installed.)
Regards,
Foot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, since installing IE7 (Final) I see the same behaviour.
For reproducing this, make sure, that KP is locked. Trying to log into a side with ctrl-alt-a and than unlocking KP fails with the message, that a wrong username has been inserted. If I unlock KP before I log in the same side, it works fine. It is reproducable and as IE 7 will be autoinstalled on the tomorrow patchday, this issue seems to me to be of highest priority.
Another notice: It doesn't seem to be the same problem, as I had reported in the past for the IE-based Maxthon browser, because with Maxthon this problem can be solved by placing a {DELAY=500} in front of the Auto-Type-sequence (still very annoying, as there is still an option missing in KP, to make a general change for the sequence instead of editing each and every single entry). This workaround works fine with Maxthon in IE 6 and in IE 7. But with IE 7 this doesn't help, even increasing the delay to 5000 doesn't change the problem.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that there appears to be some issue tied to IE 7. I too see this problem with IE 7. I do not have the problem Firefox 1.x or 2.x and did not have the problem with IE 6. I typically use Firefox, but there are times when IE is necessary. I was wondering if IE's auto-complete or auto-drop down list when you type was causing it. I was unable to recreate the problem outside of Keepass' auto-type. I'm using a MS Natural keyboard w/ US layout.
Regards,
Jeff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I placed {BS} in front of the Aut-Type-Sequence. There is no difference in the result, when I try to log in with IE7.
Just a P.S. to my previous post: The reason, why I compared the behaviour in IE7 with Maxthon is, that also in Maxthon things work fine, if KP gets unlocked before logging in (in this case no delay needed). So seeing the same in IE7 I believed, it would be the same behaviour (as it is not at least from the point of the result, as I described).
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used "Auto-Type:{BS}{USERNAME}{TAB}{PASSWORD}{ENTER}" in one of my entries and it prevented the missing character. Read that as it worked as expected. Since Thomas is still having problems it might be certain sites or field types. The site I tried suppresses any auto-complete or drop down lists. When I have some time, I'll test a few more sites.
-- Jeff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pending Thomas's reply, I can suggest the Gmail login page as an example.
I have tried to find a reproducible pattern of failures but have been unsuccessful so far. Having KeePass running before opening IE7 seemed to improve reliability but this does not always work. When it did, the first attempt to auto-type by using the global shortcut key or the context menu completed as expected. Second attempts, in the same IE session, with the same auto-type method generally failed. After the global key method failed, the first attempt with the context menu method was often successful. These sequences, however, have not been consistent.
Another complication, is that I have now seen the password lose several characters (not just the one mentioned in the title of this thread). This has occurred only once but introduces another variable.
Cheers,
Foot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at it some deeper, it seems to me, that it is actual not the problem, that the 1st letter (of the username) is missing, as I can see my username (no special signs used, just letters) correctly written; nevertheless in both sites I get a messages, that my credentials are wrong. If I unlock KP as previously described, logging in works fine.
In the second example I was able to see, that (with KP locked while pressing ctrl-alt-a) after the unlocking procedure the username and the password got both written into the username-field; it is obvious, that doing this no system will let me in. That means the {TAB} in between is ignored (but as said, only if KP is locked when starting to log in). And another observation: In the AntiVir-page placing a delay of 5000 (5 seconds, whow) helped. When I first wrote, that it doesn't do, this was on the EssentialPim-site, where 500 ms with Maxthon works since months fine.
BTW, Paul, I had tried your suggestion with BS, but I have no idea, what this should really do in this place. Whether or not it works, can you please enlighten me?
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mixed results with no clear pattern. I will describe the sequence:
1. With KeePass running, used hyperlink in KeePass entry to open IE7 and go to the EssentialPIM site. Auto-Type ran successfully from context menu.
2. Edited KeePass entry to add auto-type window text. Auto-Type ran successfully from global hot key.
3. Closed KeePass but left IE7 running at the same URL. Reopened KeePass and autotype ran successfully from context menu and then from global hot key.
4. Closed IE7. With KeePass running, used hyperlink in KeePass entry to open IE7 and go to the AntiVir site. Auto-Type ran successfully from context menu. (Did not use encryption offered on the site to send details.)
5. Editted KeePass entry to add auto-type window text. Auto-Type failed by placing password in User Name field (and nothing in the Password field). Encryption was still disabled.
6. Repeated context menu Auto-Type on the AntiVir site but it failed (in same way as global hot key method in 5).
7. In the same IE7 session, returned to the EssentialPIM site and tried Auto-Type from context menu but it failed by omitting one character of the Password.
8. Tried context menu Auto-Type again on the EssentialPIM site and it ran successfully.
Good luck,
Foot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Foot, thank you for your work.
I read your post very carefully. If I understood it correctly, you have made at least several tests with KP unlocked. Case 1,3a,4,6 must be with KP unlocked, otherwise you wouldn't have a context-menu. In the other cases I am not clear, if you global-auto-typed with KP locked or unlocked. To point it out: if I unlock KP before using (global-)auto-type, I see no problem.
The fact, that you got different results even on the same page (case 6 and 7), is really strange, especially as KP was obvioulsy unlocked in case 6.
Before I proceceed I will make clear (to prevend misunderstandings and for better reproducability) how I use KP since months (with IE 6 and Maxthon) without any problem: I press the global-hot-key ctrl-alt-a without questioning, if KP is locked or unlocked in this moment. (Mostly it is locked.) If KP is locked, I go through the unlocking-page, and things go on and work fine. Because of the known problem with Maxthon I have placed a DELAY-expression in front of the auto-type-sequence and with that it works like a charm.
Now reading Foots results (especially case 6) I wonder, if we have TWO different problems here? The first one, which seems to be related with IE7 and a second one with omitted characters.
Regarding the latter point, I remind you, that there where already discussions about this problem, which seems to be related with some special characters as ~, Caret, Apostroph and more, which do not get correctly autotyped, propably related to the localization settings. These characters act as dead keys on the (e. g. german) keyboard (for combining them with with other letters) and autotype cannot transport them correctly. This is typical, if copy / paste works, but auto-type fails. As it is hard to see, if there is such a sign in a password, that KP had created, I had suggested some time ago to divide the last groups of signs in the password generator for excluding those potentially problematic signs from the others. As long as Dominik has not done anything here, I create my passwords with the password generator with the last group deactivated and do not use the passwords, that KP auto-creates, if creating a new entry in the database. - Long text, short content: For my use I can exclude this problem, but others may have this; perhaps the different results of Foot are releted with this point?
The previous paragraph was about sorting the problems (or trying to achieve this). The real problem of this thread as I think is the IE7-compatibility. I would be happy, if this problem could get fixed. The actual situation, where I have to remember to unlock KP before logging in (as said, by doing so, I didn't see any problem till now in IE7), is not really satisfying and only good as a momentary workaround.
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to Thomas for the careful reading and my apologies for the ambiguity about locking. All of my trials have been with KeePass unlocked (including those mentioned in previous posts).
My first response to the missing characters in passwords was to try DELAY-expressions of the sort Thomas has been using. I have not tried the 5000 value Thomas mentioned earlier. At 1000, I saw no benefit. Since those tests I have removed Auto-Type templates from the individual KeePass entries and have relied only on the default Auto-Type sequence.
There have been no special characters used in the passwords I have been testing.
In summary, with KeePass always unlocked and passwords without special characters, the KeePass password field contents are sometimes (but not always) shortened by one or more characters or, less often, placed into the wrong input box (as in Cases 5 and 6 of my previous post). Dragging ang dropping fields has, so far, always been successful but I have not tried this many times.
Regards,
Foot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Same here with IE7. I've seen missing characters in the user name or password. Happens everytime on sites like gmail, spamgourmet, or sourceforge (e.g., all sites I visited since I upgraded to IE7).
Pyt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for the link; but let me point out my intention to write about this problem (as I had found the solution for myself as described): We will get some more reports (Pyt was the first, who followed) and I wanted to make clear, that we must have the dead-key-problem in mind, when trying to track down the issue (hopefully this is usefull for Dominik).
Hi Foot,
thanks again for clearing this up. Pityfully this means, that the issue seems to be even more complicated. (Nothing is worse, than a fault, that sometimes appears and than does not.)
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your link.
My conclusions out of this are the following:
There is a problem with IE7, that shows in (at least) 2 programs. The question is, is this a bug in IE7, or have there changes been made, which leed to the problem? (From the point of a user this makes no difference, but from technical point of view, it may be important.)
It seems to me (as this has been seen in both programs), that the worst case - an error, which appears not always - did come true.
Just a guess: I do not believe, that te problem has something to do with the stronger security settings in the new IE. I merely believe, that there is a timing problem (but I have no idea where). If it would be a security settings related problem, I would expect, that both apps would never work correctly. The timing issue seems more likely to me, because of the problems to easily reproduce the problem AND because (for me) the problem in KP does not exist, if I unlock KP before the logging procedure. So I guess, that there take place any procedures in or in conjunction with IE7 which need a little more time than with IE6, just an amount of time, which in not clearly predictable situations / environments lead to the problem arising or get handled quick enough, so that the problem does not appear. And - if a bug or a feature in IE7 - this gives me the hope, that Dominik will be able to do something about it. May be, that the neccessary changes lead to a little bit slower respondance of KP, but we should be able to live with that. (Rereading the discussion at moonsoftware I found, that the author of Password Agent said, that he corrected some timing adjustments for better Vista-compatibility in his new beta. The results for that are not yet availible, but the idea seems to go in the same direction.)
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some more trials show that adding a single letter followed by {BS} after {USERNAME}{TAB} produces reliable results on each of the three sites previously mentioned by Thomas and me. This works with both the global hot key and the context menu. With the global hot key, it does not matter whether KeePass is locked or unlocked when running the key.(In all cases, I have included a specific Auto-Type-Window string in the KeePass database entry.)
It is essential to have the cursor flashing at the beginning of the User Name input box on the site. The misplaced results in points 5 and 6 of my post on 2006-11-15 18:07 may have resulted from incorrect focus.
Regards,
Foot
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sometimes when i use the autotype keepass misses the first letter,,, or sometimes the first letter comes out but is in lowercase when it should be upper case...
what is causing this problem?
This is an unusual error.
Do you have other keyboard software loaded? Do you use an unusual keyboard?
Can you auto-type into Notepad to check that it is not your keyboard?
What software are you using when auto-type fails?
cheers, Paul
Hello Paul,
I have exactly the same problem. After your suggestion I checked, and the unusual thing I have is a Logitech keyboard, with Logitech software (SetPoint) running. If I close SetPoint, the problem dissapears. If I open back SetPoint, I have the behaviour again, no first letter.
Another thing I think I have noticed is that if I modify something on the entry of KeePass and then autotype, even with SetPoint working it will work. After the save, will stop working with the first letter behavior.
Best regards,
Julio
Which browser do you use?
For Maxthon such kind of behaviour is known.
Thomas
i use IE, gaim, thunderbird, norton, keepass are the only things loaded. my keyboard is normal, no software for it... it USUALLY works fine, just every once in a while it wont work (until i exit and reload keepass i believe)
you could also try KeeForm, if you problems with auto-type.
I have also found the same issue in IE7 only. Auto-typing to Opera 9.02 and Firefox 2.0 seems consistently okay. Results in Notepad are also reliable. (Keyboard is the internal keyboard of a Dell Inspiron 9400 laptop with US layout and no special keyboard software installed.)
Regards,
Foot
Yes, since installing IE7 (Final) I see the same behaviour.
For reproducing this, make sure, that KP is locked. Trying to log into a side with ctrl-alt-a and than unlocking KP fails with the message, that a wrong username has been inserted. If I unlock KP before I log in the same side, it works fine. It is reproducable and as IE 7 will be autoinstalled on the tomorrow patchday, this issue seems to me to be of highest priority.
Another notice: It doesn't seem to be the same problem, as I had reported in the past for the IE-based Maxthon browser, because with Maxthon this problem can be solved by placing a {DELAY=500} in front of the Auto-Type-sequence (still very annoying, as there is still an option missing in KP, to make a general change for the sequence instead of editing each and every single entry). This workaround works fine with Maxthon in IE 6 and in IE 7. But with IE 7 this doesn't help, even increasing the delay to 5000 doesn't change the problem.
Thomas
I agree that there appears to be some issue tied to IE 7. I too see this problem with IE 7. I do not have the problem Firefox 1.x or 2.x and did not have the problem with IE 6. I typically use Firefox, but there are times when IE is necessary. I was wondering if IE's auto-complete or auto-drop down list when you type was causing it. I was unable to recreate the problem outside of Keepass' auto-type. I'm using a MS Natural keyboard w/ US layout.
Regards,
Jeff
What happens if you add something like a backspace at the beginning of the typing sequence?
cheers, Paul
Hi Paul,
I placed {BS} in front of the Aut-Type-Sequence. There is no difference in the result, when I try to log in with IE7.
Just a P.S. to my previous post: The reason, why I compared the behaviour in IE7 with Maxthon is, that also in Maxthon things work fine, if KP gets unlocked before logging in (in this case no delay needed). So seeing the same in IE7 I believed, it would be the same behaviour (as it is not at least from the point of the result, as I described).
Thomas
Paul,
I used "Auto-Type:{BS}{USERNAME}{TAB}{PASSWORD}{ENTER}" in one of my entries and it prevented the missing character. Read that as it worked as expected. Since Thomas is still having problems it might be certain sites or field types. The site I tried suppresses any auto-complete or drop down lists. When I have some time, I'll test a few more sites.
-- Jeff
Thomas, is this site specific? Can you provide a sample of a site where you have this problem?
cheers, Paul
Paul,
Pending Thomas's reply, I can suggest the Gmail login page as an example.
I have tried to find a reproducible pattern of failures but have been unsuccessful so far. Having KeePass running before opening IE7 seemed to improve reliability but this does not always work. When it did, the first attempt to auto-type by using the global shortcut key or the context menu completed as expected. Second attempts, in the same IE session, with the same auto-type method generally failed. After the global key method failed, the first attempt with the context menu method was often successful. These sequences, however, have not been consistent.
Another complication, is that I have now seen the password lose several characters (not just the one mentioned in the title of this thread). This has occurred only once but introduces another variable.
Cheers,
Foot
Hi Paul, Jeff
I will give you 2 addresses, where I see the problem:
http://www.essentialpim.com/forum/index.php
http://forum.antivir-pe.de/index.php
Looking at it some deeper, it seems to me, that it is actual not the problem, that the 1st letter (of the username) is missing, as I can see my username (no special signs used, just letters) correctly written; nevertheless in both sites I get a messages, that my credentials are wrong. If I unlock KP as previously described, logging in works fine.
In the second example I was able to see, that (with KP locked while pressing ctrl-alt-a) after the unlocking procedure the username and the password got both written into the username-field; it is obvious, that doing this no system will let me in. That means the {TAB} in between is ignored (but as said, only if KP is locked when starting to log in). And another observation: In the AntiVir-page placing a delay of 5000 (5 seconds, whow) helped. When I first wrote, that it doesn't do, this was on the EssentialPim-site, where 500 ms with Maxthon works since months fine.
BTW, Paul, I had tried your suggestion with BS, but I have no idea, what this should really do in this place. Whether or not it works, can you please enlighten me?
Thomas
Hmm, Thomas and Foot get different results. This is not good. Foot, can you try the URLs Thomas provided.
Thomas, the BS suggestion was to provide a first character as you said the first character was lost.
cheers, Paul
Hi Paul,
Mixed results with no clear pattern. I will describe the sequence:
1. With KeePass running, used hyperlink in KeePass entry to open IE7 and go to the EssentialPIM site. Auto-Type ran successfully from context menu.
2. Edited KeePass entry to add auto-type window text. Auto-Type ran successfully from global hot key.
3. Closed KeePass but left IE7 running at the same URL. Reopened KeePass and autotype ran successfully from context menu and then from global hot key.
4. Closed IE7. With KeePass running, used hyperlink in KeePass entry to open IE7 and go to the AntiVir site. Auto-Type ran successfully from context menu. (Did not use encryption offered on the site to send details.)
5. Editted KeePass entry to add auto-type window text. Auto-Type failed by placing password in User Name field (and nothing in the Password field). Encryption was still disabled.
6. Repeated context menu Auto-Type on the AntiVir site but it failed (in same way as global hot key method in 5).
7. In the same IE7 session, returned to the EssentialPIM site and tried Auto-Type from context menu but it failed by omitting one character of the Password.
8. Tried context menu Auto-Type again on the EssentialPIM site and it ran successfully.
Good luck,
Foot
Hi Paul, thank you for the clear-up.
Hi Foot, thank you for your work.
I read your post very carefully. If I understood it correctly, you have made at least several tests with KP unlocked. Case 1,3a,4,6 must be with KP unlocked, otherwise you wouldn't have a context-menu. In the other cases I am not clear, if you global-auto-typed with KP locked or unlocked. To point it out: if I unlock KP before using (global-)auto-type, I see no problem.
The fact, that you got different results even on the same page (case 6 and 7), is really strange, especially as KP was obvioulsy unlocked in case 6.
Before I proceceed I will make clear (to prevend misunderstandings and for better reproducability) how I use KP since months (with IE 6 and Maxthon) without any problem: I press the global-hot-key ctrl-alt-a without questioning, if KP is locked or unlocked in this moment. (Mostly it is locked.) If KP is locked, I go through the unlocking-page, and things go on and work fine. Because of the known problem with Maxthon I have placed a DELAY-expression in front of the auto-type-sequence and with that it works like a charm.
Now reading Foots results (especially case 6) I wonder, if we have TWO different problems here? The first one, which seems to be related with IE7 and a second one with omitted characters.
Regarding the latter point, I remind you, that there where already discussions about this problem, which seems to be related with some special characters as ~, Caret, Apostroph and more, which do not get correctly autotyped, propably related to the localization settings. These characters act as dead keys on the (e. g. german) keyboard (for combining them with with other letters) and autotype cannot transport them correctly. This is typical, if copy / paste works, but auto-type fails. As it is hard to see, if there is such a sign in a password, that KP had created, I had suggested some time ago to divide the last groups of signs in the password generator for excluding those potentially problematic signs from the others. As long as Dominik has not done anything here, I create my passwords with the password generator with the last group deactivated and do not use the passwords, that KP auto-creates, if creating a new entry in the database. - Long text, short content: For my use I can exclude this problem, but others may have this; perhaps the different results of Foot are releted with this point?
The previous paragraph was about sorting the problems (or trying to achieve this). The real problem of this thread as I think is the IE7-compatibility. I would be happy, if this problem could get fixed. The actual situation, where I have to remember to unlock KP before logging in (as said, by doing so, I didn't see any problem till now in IE7), is not really satisfying and only good as a momentary workaround.
Thomas
You can see what password has been typed by omitting the ENTER and the running the free AsteriskKey from http://www.lostpassword.com/.
cheers, Paul
Hi Paul and Thomas,
Thanks to Thomas for the careful reading and my apologies for the ambiguity about locking. All of my trials have been with KeePass unlocked (including those mentioned in previous posts).
My first response to the missing characters in passwords was to try DELAY-expressions of the sort Thomas has been using. I have not tried the 5000 value Thomas mentioned earlier. At 1000, I saw no benefit. Since those tests I have removed Auto-Type templates from the individual KeePass entries and have relied only on the default Auto-Type sequence.
There have been no special characters used in the passwords I have been testing.
In summary, with KeePass always unlocked and passwords without special characters, the KeePass password field contents are sometimes (but not always) shortened by one or more characters or, less often, placed into the wrong input box (as in Cases 5 and 6 of my previous post). Dragging ang dropping fields has, so far, always been successful but I have not tried this many times.
Regards,
Foot
Same here with IE7. I've seen missing characters in the user name or password. Happens everytime on sites like gmail, spamgourmet, or sourceforge (e.g., all sites I visited since I upgraded to IE7).
Pyt.
Hi Paul,
thank you for the link; but let me point out my intention to write about this problem (as I had found the solution for myself as described): We will get some more reports (Pyt was the first, who followed) and I wanted to make clear, that we must have the dead-key-problem in mind, when trying to track down the issue (hopefully this is usefull for Dominik).
Hi Foot,
thanks again for clearing this up. Pityfully this means, that the issue seems to be even more complicated. (Nothing is worse, than a fault, that sometimes appears and than does not.)
Thomas
Hi Paul and Thomas,
You may find this discussion (http://www.moonsoftware.com/forum/topic.asp?TOPIC_ID=535) interesting.
Cheers,
Foot
Hi Foot,
Thank you for your link.
My conclusions out of this are the following:
There is a problem with IE7, that shows in (at least) 2 programs. The question is, is this a bug in IE7, or have there changes been made, which leed to the problem? (From the point of a user this makes no difference, but from technical point of view, it may be important.)
It seems to me (as this has been seen in both programs), that the worst case - an error, which appears not always - did come true.
Just a guess: I do not believe, that te problem has something to do with the stronger security settings in the new IE. I merely believe, that there is a timing problem (but I have no idea where). If it would be a security settings related problem, I would expect, that both apps would never work correctly. The timing issue seems more likely to me, because of the problems to easily reproduce the problem AND because (for me) the problem in KP does not exist, if I unlock KP before the logging procedure. So I guess, that there take place any procedures in or in conjunction with IE7 which need a little more time than with IE6, just an amount of time, which in not clearly predictable situations / environments lead to the problem arising or get handled quick enough, so that the problem does not appear. And - if a bug or a feature in IE7 - this gives me the hope, that Dominik will be able to do something about it. May be, that the neccessary changes lead to a little bit slower respondance of KP, but we should be able to live with that. (Rereading the discussion at moonsoftware I found, that the author of Password Agent said, that he corrected some timing adjustments for better Vista-compatibility in his new beta. The results for that are not yet availible, but the idea seems to go in the same direction.)
Thomas
Some more trials show that adding a single letter followed by {BS} after {USERNAME}{TAB} produces reliable results on each of the three sites previously mentioned by Thomas and me. This works with both the global hot key and the context menu. With the global hot key, it does not matter whether KeePass is locked or unlocked when running the key.(In all cases, I have included a specific Auto-Type-Window string in the KeePass database entry.)
It is essential to have the cursor flashing at the beginning of the User Name input box on the site. The misplaced results in points 5 and 6 of my post on 2006-11-15 18:07 may have resulted from incorrect focus.
Regards,
Foot