[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: *text-restricted-dialog-item*
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Fri, 06 Mar 92 13:54:19
- Cc: email@example.com
As I convert my 1.3.2 code to
> 2.0 code, I hope I'll be able to contribute something useful.
This class of
> dialog items is useful in a variety of situations.
> (defclass *text-restricted-dialog-item* (editable-text-dialog-item)
> ((max-length :initarg :max-length :accessor max-length)
> (char-set :initarg :char-set :accessor char-set))
> :max-length nil
> :char-set nil))
Bravo! Restricting user input is useful MOST times an editable text
dialog is required.
Having worked on much hairier systems that have a superset of this
functionality, let me guide further development by offering this
The user needs to know the status of the currently being typed in string
on a character-by-character basis. There are four possible states:
1. The current string can match a correct result if extended.
2. The current string is a correct result
3. Both one and two
4. Neither one or two.
It would be nice to find an intuitive display of these two bits that
didn't take up much space in the dialog.
Two more pieces of information should be available to the user, perhaps
with balloon help, or some other action requiring just a little effort:
5. What are the legal possbile results
6. Given the current string, what are the legal possible extensions.
Number five is generally taken care of by static text within the dialog
[though usually not well].
Number six is the hard part and requires dynamic examination of the
current string. Often this is simply forgone and the programmer expects
five to suffice. Neither of these must be definitive, but the more so,
One way to tell the user what he needs to know WHEN he needs to know it
is to pop up a dialog containing number six [or number five, if six not
available] only when state 4 is reached.
The situation is common and complex enough that standard user interface
guidelines would help everybody. Specifically: How to display the above
2 bits, and what to do when an illegal state is reached. Once we have a
standard, system support for easing programming of it would increase the
likelyhood of its general adoption.
In the mean time, a function that has too much flexibility, takes lots
of keywored args [which have reasonable defaults] would help us explore
the possibility space.
hohmann has a piece of that. Thanks to MCL view-key-event-handler, all
this is easily possible. [thanks to Jeremy Jones!]