Skip to main content

Beware of Using AutoComplete for everything

(note: Yes, I know the first version refered to using .T. - it's been updated)

VFP's AutoComplete feature totally rocks. You turn it on and you've immediately provided a valuable tool for any data entry application where repetition is almost always a way of life. So valuable that you might be tempted to turn it on in your base text box class. In a word (ok it's a contraction so maybe two words) , don't.

The reason? AutoComplete works with password fields.

Huh?

AutoComplete has several properties but the most common one is simply to set AutoComplete property to a value other than 0. When this happens, FoxPro "magically" remembers the previous entry and recalls them in a selectable list each time the user comes back into it and enters the same first letter.

This "magic" isn't all that special : default, the file AUTOCOMP (located in your application data folder or current folder for runtime) contains 7 fields: source (the object name), data (the value entered), count (number of times used), weight (if using the value of 4 for AutoComplete), Created timestamp, Updated timestamp and a custom user field. When you enter the key, FoxPro looks into this table (which you can change by specifying the AutoCompTable property) for the object name (which may be overridden with the AutoCompSource property) and then displays it.

The real problem? AutoComplete still runs even when the PasswordChar property is set.

PasswordChar is the property that changes all of the text entered into a text box into that character (typically a star). While you can still refer to the Value property to refer to what the user entered in, the user can't see it directly - it appears like a "password" would in "*****".

BUT if you have AutoComplete set to work (a value of 1,2,3,4) , FoxPro continues to think you want that extra feature turned on. So you have a form prompting for a password, and if your password was FoxPro, as soon as you enter F, FoxPro shows up in the list (not hidden behind the Password character).

Now, in most cases, a developer may have their own txtPassword class or something similar, but it may still be based on a common text class.

Does using AutoComplete make for a good User interface? It's hard to say - many users like it - while others may find it distracting. However, just "trying" it in your application will make this definitely unwanted effect appear.

Consider yourself warned.

I wonder if it's the same with other languages...

Comments

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site: http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older. Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments. But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward. FoxPro VFP