I often bump into several sites where for various inputs they use comboboxes which do not take their value as input. They're so poorly written that they won't even take the regular alt+down properly (the combo drops and in split of a second it goes away)
The only solution I found so far was to use {down} as many times as the value I want to be selected.
This generally works fine except for at least 1 scenario: in my case, credit card details, where I have expiration month and year.
These values change every 2/3 years so I have to keep uipdating a bunch of auto type definitions for the various sites to update the number in {down X} Sadly I only catch up on this after the payment is refused due to invalid CC data.
I was thinking it would be almost trivial to have beside {Key <number>} also a {Key string}, where string is one of the string fields defined for that entry. Of course, validated to be a number.</number>
Thanks.
My CC details are never entered via Auto-Type. Safer methinks.
I keep my expiry as two fields, Month and Year. Most sites require manual input after viewing the record, but sometimes I can drag n drop.
cheers, Paul
Is keepass hackable? Because if not, I don't see why it isn't safe enough, unless you're not using dual channel autotype.
I also keep my expiry as 2 fields, not sure how you could auto type otherwise...
I never bumped into manual input requirements so far (10+ years of internet shopping, and at least 6 years since using keepass with autotyope for this). We're probably surfing different sites, but anyway, not really to the point of my improvement/feature ;)
Cheers.
What is the advantage editing a custom string field compared to editing a keystroke sequence? They are the same click depth.
Say you have 10 auto type windows with different auto type sequences (cause some sites requires another count of tab-ing to get to the right field, or the fields are not in the expected "normal" order), etc. I personally have about 7 of them. 2 or 3 of those require the {down x} method for autotype.
If you edit the custom string field, you do it once. If you edit the autotype sequence, you go through each one to see which requires update, and update the needed one. Provided you recall to do that.
I have 3 cards :| different dates, but still.
Right, I can see where the feature might save some work.
However, I don't believe that the Spr-compiler does recursive evaluation of keystroke sequences, so this feature might not end up on the short list.
Of course it is, everything is.
I meant safer from the "don't enter stuff into the wrong place / site" perspective.
cheers, Paul
Small update. I figured I'll start implementing this myself so after a small debugging it turns out the following (although deemed wrong) will work. For now, at least.
"{DOWN {S:ExpirationMonth}}"
where ExpirationMonth is an advanced string field which must contain a number.
For the year part expression evaluation is needed to support something like
"{DOWN {EXPR {S:ExpirationYear}-{DT_YEAR}}}"
I'll see if I can get the time to do that.