setting pointer location

[David Vaughan]

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 
> noted),
...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 
> scene.
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 
clearing data.
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 
computer-mode oriented.

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.

cheers
David

>
> Rob Cozens
> CCW, Serendipity Software Company
> http://www.oenolog.com/who.htm
>
> "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
> http://lists.runrev.com/mailman/listinfo/use-revolution
>