setting pointer location
dvk at dvkconsult.com.au
Sat Dec 28 15:36:00 EST 2002
On Sunday, Dec 29, 2002, at 04:30 Australia/Sydney, Rob Cozens wrote:
> OenoLog takes a middle ground: while the field cursor tabs to the open
> field (leaving the mouse cursor in its original location as David
...further refining this difference between data entry and general
mouse movement, the cursor will hide as soon as the user then starts
typing. If the cursor is "lost" to the user then you are probably
entitled to make it reappear wherever makes sense when they tab or
press enter from the last field, or next move the mouse, as the user's
last focus was the entry point. So, you might move it yourself on
closeField (the cursor has already vanished) but not on exitField or
mouseMove (it was still visible). (I just tried this and the cursor did
not move anyway but I am not going to explore that as I don't have a
user for it).
> ... This is displayed in a manner that appears to be columnar; but I
> don't want people tabbing into the whole table, so to accommodate
> adding and editing table rows there is an individual field below each
> column. If I were to use Alan's technique, I could eliminate those
> individual fields and construct/deconstruct individual rows behind the
I also find this question of how data entry is done interesting. We
have the approach of entering directly in fields, doing it in a second
set where the original fields are columnar or group-scrolling, and
using separate dialogs. For columnar/group scrolling fields I have
preferred the separate fields approach, because sync scrolling for data
entry jammed at the bottom of the field is a bit messy. It also allows
me to use a concept from Dataflex to get rid of "New" and "Edit"
modalities previously mentioned. Adjacent to the entry fields are
"Clear", "Delete" and "Save" buttons.
If the user enters new data in empty fields then (assuming no autofind)
pressing save will add a record while delete is not available.
If they call up an existing record (autofind or click on the list to
put it in the entry fields) then they can delete it or modify and save,
in which case it will be an update.
After any save, the data is left in the fields (not auto-cleared) but
internal status is set to new record so you can enter a new variation
of the previous one. Depending on the application it can be better to
leave state as found record until they press Clear.
Clear obviously sets internal status for a new record as well as
The advantage is simply that you work on the data, with mode determined
after the fact (and a little behind the scenes work) rather pressing a
button to select new or edit modes before doing anything. It is a
little faster for the user, being more data oriented rather than
Based on Alan's comments about using ask/answer data entry, I am now
considering using modeless dialogs rather than additional fields on the
same card as the data entry point, bringing up the right dialog (field
set) for the logical sub-group of fields selected on this card. This
will reduce clutter on the card and localise entry and validation.
just more thinking out loud in response to yours.
> Rob Cozens
> CCW, Serendipity Software Company
> "And I, which was two fooles, do so grow three;
> Who are a little wise, the best fooles bee."
> from "The Triple Foole" by John Donne (1572-1631)
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode