Re: *text-restricted-dialog-item*

[cfry@MIT.EDU (Christopher Fry)]

 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))
>   (:default-initargs
>     :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 
obvervation.
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, 
the better.

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!]