Subject: fields design -- proposed edit/select behaviors
From: Paul Rohr (paul@abisource.com)
Date: Wed Jun 07 2000 - 16:11:58 CDT
The following is an attempt to specify the desired behavior for the
following operations on existing fields:
- selection
- cursor motion
- typing
- deletions
- updates
- undo
- etc.
There are a lot of behavioral subtleties here, so if anyone knows of
something I've missed here, this is a perfect time to speak up. It's a lot
easier to ensure that we can handle stuff like this if it gets designed in
from the beginning.
intro
-----
The basic idea is pretty simple -- fields are just containers for calculated
text, which can be updated later if needed. They thus have a length which
corresponds exactly to the length of the contained text (which may change).
updates
-------
The properties on the field can be used to calculate new contents for the
field. This update is done once when the field is originally created.
After that, updates can be triggered to recalculate the field contents in
the following ways:
1. Manual update. Context menus for any selection which overlaps one or
more fields should add an "Update Field" context menu to do this.
2. Automatic update. This is quite rare, and seems to be tied to some
other event, such as loading, printing, saving, or repaginating the
document. The current approach of constantly forcing updates is almost
certainly overkill.
While the triggering mechanisms can be generalized, the specific update
logic invoked is field-specific. For example, some updates simply restore
the contents of a field (CreateDate), while others calculate a new value
(Time).
undo
---- Any manual update to the contents of a field should have the usual undo/redo semantics. The applicability of undo semantics to automatic updates needs further investigation.display ------- Whenever the cursor is inside a field, the background of the entire field toggles, to visually indicate that the user is inside a field. We should choose a background color which is visually distinct from our usual selection color, though.
Otherwise, the contents of a field feel an awful lot like normal text. In most cases, you can select, format, delete, and even insert text into a field's contents.
In particular, you *can* apply partial formatting inside a field. However, most or all such changes are lost if the field is ever updated. One worthwhile exception is formatting which applies to the entire field.
insert semantics ---------------- Insert semantics within an editable field are as usual -- add the text immediately after the insertion point.
Insert semantics at field boundaries are as follows:
- left: display the field background (so you know it's there), but any inserted text goes before the field
- right: don't display the field backgroung (you're past it), and any inserted text goes after the field
Thus, you can't insert text at the beginning or end of a field's contents. Poor baby.
delete semantics ---------------- Delete semantics within an editable field are as usual. Delete semantics at field boundaries are as follows:
- left: forward delete selects the entire field. another delete nukes it. backspace operates as usual
- right: backspace selects the entire field. another backspace nukes it. foreward delete operates as usual
This is actually pretty nice behavior.
Note however that if you want to completely delete the contents of a field without deleting the field itself, that *is* possible. It's just not easy. ;-)
double-click semantics ---------------------- For most fields, double-click should select the entire field (#223), so for now let's just do that for all fields.
It looks like Word also has extra logic to interpret smaller-granularity double-clicks for subfields of a formatted date/time string, but someone clever can add that back in later, if needed.
Paul
This archive was generated by hypermail 2b25 : Wed Jun 07 2000 - 16:06:22 CDT