Change 'Scheduled for Production' to 'Has Been Produced' ... UI suggestions?

[Clif McIrvin]

(I changed the topic ... the original post is at the bottom if you want
to see it.
(My new question is down a few lines to set the context.--Clif)

I noticed that you said this:

In the Production Date _Enter event procedure [...]

... and this:

My idea was to automatically change the 'not yet produced' date to
the
'last date entered' when the user enters the date produced field,

If you'll pardon me for saying so, this strikes me as a singularly bad
idea.
Changing data just because a control receives the focus is a very
dangerous
business. Normally a user expects to be able to tab through or click
into
any field in any record without changing any data.

Absolutely. On the other hand, re-typing the same date 25 or 40 times
does tend to get annoying as well.

If you don't let them do
that, I think you're going to have confused and annoyed users.
Wouldn't it
make more sense to use AfterUpdate events of some controls to trigger
correlated data changes to other controls, where appropriate? Or else
the
Click events of command buttons, where people know that they are
asking for
some action to be taken in response to the click?

I don't really understand your description fully, so I may be off-base
here,
but I think you may be creating problems for yourself. The fact that
you're
asking to do something that Access has no built-in ability to do is a
suggestion that, at the very least, your approach is very unusual and
maybe
should be re-examined.

(Not the first time I've been accused of thinking in a non-standard
manner! <g>)

Dirk, I easily follow what you are saying here. In this particular case
the user is in the form to change the production date of several
existing records to the current production date (never today's date.) In
the majority of the cases, the production date is the only column that
needs to be changed, so the After Update event doesn't appear to be a
good fit.

As the daily production run is arbitrary, and the 'scheduled for
production' items are sorted by item number I have found no more
straight-forward way of selecting the items to be updated then to simply
scroll through the not yet produced items.

My revised question (and if it's outside the scope of the forum then
I've really not lost anything by asking) is:

How would you (and I'm certainly not directing this only to Dirk!)
suggest that I design the user interface?

Some greatly simplified sample data (I have the form in datasheet view):

Date
Produced Job ID Item Etc...
1/01/2099 ABC 1
1/01/2099 ABC 2
1/01/2099 ABC 3
1/01/2099 DEF 1
1/01/2099 DEF 2
1/01/2099 DEF 3

And the day's production log might show DEF-3, ABC-1 and DEF-1 (etc.)

The number of pieces on any day's production will almost always be less
than 30, and the number of pieces in pre-production will vary widely --
I have seen over 200 pieces in pre-production status at one time.

Assuming that 1) the only value that needs to be changed is the
production date (there are occasions when other controls require data
entry, but that is the exception) and 2) minimizing keystrokes and / or
mouse clicks is a design objective what recommendations do you have for
me?

 

[Graham R Seach]

Clif,

Let's look at your goals from a modelling perspective. Let me know if this
is incorrect.

1. Mark produced items that have not already been so marked.
1.1 Find produced items that have not already been so marked.
1.1.1 Find records that meet certain criteria.
1.1.2 Filter out, or ignore records that do not meet other
criteria.
1.2 Select specific items to be marked.
1.2.1 Select items to be marked.
1.2.2 Unselect items not to be marked.
1.3 Issue command to mark selected records.
1.3.1 ????Steps to do this????
1.4 Verify operation status.
1.5 Respond to operation status.

This would suggest that the user will expect a "set process"; meaning, the
user will expect to be able to mark multiple records simultaneously, rather
than mark individual records one after another. This is what the user will
expect - but does not necessarily suggest how the operation will actually be
carried out. Therefore, I'd suggest creating a form that allows you to:

* Find a bunch of records that satisfy the criteria for items that have been
produced but not marked as such;
* Select all those records (or a subset of them) that the user actually
wants to mark;
* Execute the 'mark' operation; and
* Respond to the results of the operation (success or failure).

My guess would be to create a new form containing a listbox (with its
MultiSelect property set to Simple or Extended) to show all the records of
interest. The user should then be able to select/unselect all/specific
records for marking.Then using the listbox's SelectedItems collection, mark
the records one-at-a-time.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

(I changed the topic ... the original post is at the bottom if you want to
see it.
(My new question is down a few lines to set the context.--Clif)

I noticed that you said this:

In the Production Date _Enter event procedure [...]

... and this:

My idea was to automatically change the 'not yet produced' date to the
'last date entered' when the user enters the date produced field,

If you'll pardon me for saying so, this strikes me as a singularly bad
idea.
Changing data just because a control receives the focus is a very
dangerous
business. Normally a user expects to be able to tab through or click
into
any field in any record without changing any data.

Absolutely. On the other hand, re-typing the same date 25 or 40 times does
tend to get annoying as well.

If you don't let them do
that, I think you're going to have confused and annoyed users. Wouldn't
it
make more sense to use AfterUpdate events of some controls to trigger
correlated data changes to other controls, where appropriate? Or else
the
Click events of command buttons, where people know that they are asking
for
some action to be taken in response to the click?

I don't really understand your description fully, so I may be off-base
here,
but I think you may be creating problems for yourself. The fact that
you're
asking to do something that Access has no built-in ability to do is a
suggestion that, at the very least, your approach is very unusual and
maybe
should be re-examined.

(Not the first time I've been accused of thinking in a non-standard
manner! <g>)

Dirk, I easily follow what you are saying here. In this particular case
the user is in the form to change the production date of several existing
records to the current production date (never today's date.) In the
majority of the cases, the production date is the only column that needs
to be changed, so the After Update event doesn't appear to be a good fit.

As the daily production run is arbitrary, and the 'scheduled for
production' items are sorted by item number I have found no more
straight-forward way of selecting the items to be updated then to simply
scroll through the not yet produced items.

My revised question (and if it's outside the scope of the forum then I've
really not lost anything by asking) is:

How would you (and I'm certainly not directing this only to Dirk!) suggest
that I design the user interface?

Some greatly simplified sample data (I have the form in datasheet view):

Date
Produced Job ID Item Etc...
1/01/2099 ABC 1
1/01/2099 ABC 2
1/01/2099 ABC 3
1/01/2099 DEF 1
1/01/2099 DEF 2
1/01/2099 DEF 3

And the day's production log might show DEF-3, ABC-1 and DEF-1 (etc.)

The number of pieces on any day's production will almost always be less
than 30, and the number of pieces in pre-production will vary widely -- I
have seen over 200 pieces in pre-production status at one time.

Assuming that 1) the only value that needs to be changed is the production
date (there are occasions when other controls require data entry, but that
is the exception) and 2) minimizing keystrokes and / or mouse clicks is a
design objective what recommendations do you have for me?
--
Clif
Still learning Access 2003

Cliff -

It's perfectly possible to move the mouse pointer to a particular
control --
so long as it's a control that can receive the focus -- but it involves a
bit of moderately complex code to call some Windows API functions.
There's
no built-in method to move the mouse pointer, the way there is to set the
focus. (Bear in mind that a control may have the focus and be the active
control regardless of where the mouse pointer is.) Do you want to give
the
API code a shot? If so, I'll post it.

It may be that just setting the focus to the control you want will serve
your needs. If so, that's easy enough: just execute the statement

YourControlName.SetFocus

And you may not need to do this at all. I noticed that you said this:

 

[Clif McIrvin]

Clif,

Let's look at your goals from a modelling perspective. Let me know if
this is incorrect.

1. Mark produced items that have not already been so marked.
1.1 Find produced items that have not already been so marked.
1.1.1 Find records that meet certain criteria.
1.1.2 Filter out, or ignore records that do not meet other
criteria.
1.2 Select specific items to be marked.
1.2.1 Select items to be marked.
1.2.2 Unselect items not to be marked.
1.3 Issue command to mark selected records.
1.3.1 ????Steps to do this????
1.4 Verify operation status.
1.5 Respond to operation status.

I like it! You just stretched my awareness of how to approach the
issue. Late last week I was looking at Arvin Meyers' ComboBox.zip
(http://www.accessmvp.com/Arvin/Combo.zip) and thinking that I could use
that concept, and here you clarify the thinking for me.

My guess would be to create a new form containing a listbox (with its
MultiSelect property set to Simple or Extended) to show all the
records of interest. The user should then be able to select/unselect
all/specific records for marking.Then using the listbox's
SelectedItems collection, mark the records one-at-a-time.

So far I've done all my selection work with combo boxes, so I'm going to
have to get acquainted with list boxes.

Thanks for the thoughts!