Controlling data entry based on Option selected

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am working on a database for tracking customer issues. I have had one (1)
very basic Access 2003 class... And I am a blonde (handy excuse...) so I
need lots of help. Here is a basic breakdown:

I have a form based on a table that has several option groups. Each of the
groups follows this format:

OptionGroup1: Customer Notified of Immediate CA? (yes/no)
OptionGroup2: Customer Notified of Short Term CA? (yes/no)
OptionGroup3: Customer Notified of Permanent CA? (yes/no)
OptionGroup4: CA Implemented by PCA (yes/no)

Based on a 'Yes' answer to any of the "customer notified' groups, I want to
open a field on the table to enter the date the customer was notified. If
the answer is 'No', hide the relevant date field & go to the next option
group.

This should be fairly easy to accomplish since the table has a field for
each of the above groups answers and dates, but I can't figure out how to
make it work. Any help would be greatly appreciated.
 
Your users could get confused by controls (not fields) that appear and
disappear. In order to make things more user friendly try to use the
"KISS" rules" Keep It Straightforward and Simple". To that end I
suggest that you always present the properly labeled controls to hold
the date a customer was notified of certain events. If a date is
present in the field and control then the customer was notified. If
there is no date then that customer wasn't notified. That also
removes the need for separate Boolean fields to track the check boxes.
Now your user will have just one thing to do for any of those events
rather than two.

HTH
 
Larry,
I really appreciate the response. It makes sense in one respect to keep the
field visible, but I want to make the date a mandantory entry for a "yes"
type answer. Can I do this by making the field visible, but non-selectable
for a "No" answer?
 
Implicit in my suggestion was that the options would go away - both as
controls on your form and in the underlying table. There is always a
risk when you ask for help that the responder (me in this case) will
nut answer your question directly but will suggest an alternate
design. That's what happened here.

My suggestion is still that you get rid of the options and of
alllowing your user to make an entry only if s/he checks a box
indicating the need for that entry.

If you think your users need the extra help and reminders, consider
crouping those well labelled controls under a label that you add that
says something like "Enter a date below only when the described action
is true". Your new users will read the label and understand. As they
get used to using that form, their eyes will just skip over that lebel
as they look for their current action item.

I might turn this around and ask "What extra value comes with making
your users check a box to say they need to enter data into a control
before presenting that control and allowing them to use it"? What
value does that extra step bring?

Be aware always that you control your own design.

Other thoughts:
An option group is used to hold options that are mutually
exclusive. By putting several options withing an option group bhey
become mutually exclusive and you are saved having to write the code
to make it happen. Is that your intent?

If I've misunderstood badly then please post back giving a complete
description of what real world (not the Access) effects you're trying
to achieve.

HTH
 
Larry,
My application is to track customer complaints that come to my manufacturing
location through a centralized customer service group. I can just have the
CS rep put in a date that the response was sent, but I would rather know
whether they actually did send a response to the customer or if they just
chose to keep the answers within the company. That is what the yes/no option
is to answer. The date field just tells me when they sent the response (if
they did). Also, some of our corrective actions are implemented by a design
change to the unit in question. This is another option group that tells me
if a design change was made & what the design documentation number is (if one
is made). I can do without the options & just let the date or PCA (change
document) number answer yes/no to the questions, but wanted a little more
complete information.

Perhaps, instead of the option group, just use buttons to check 'Done' and
the field for when?
 
Thanks for the more complete info. It helps.

What I suggest is that you actually add more fields in the table and
controls on your form. I would put in a separate date field for each
event and additional note fields and controls where they are required.
A cautionary clause to the KISS concept is "But no simpler than it
needs to be".

Instead of me changing your design, I should just respond to your
original question and hope that the other ideas I've suggested are of
use to you.

To do what you originally requested, put code in the OnCurrent event
of your form like the below for each option/textbox set:

If me!OptionName=true then
me!MyTextBox.visible = true
'me!myTextBox.enabled=true
else
me!MyTextBox.visible=false
'me!MyTextBox.enabled=true
end if

Then put the same code into the OnChange event of each option,
changing control names as required.

HTH
 
Larry,
I finally got a chance to try this logic & I am not finding the OnCurrent
event field in the properties. I do see the OnChange event field, but not
the OnCurrent. I know I am overlooking something - but I can't figure that
one out...

TIA,
Ruth
 
Larry,
I finally got a chance to try this logic & I am not finding the OnCurrent
event field in the properties. I do see the OnChange event field, but not
the OnCurrent. I know I am overlooking something - but I can't figure that
one out...

Make sure you're looking at the Form's properties (not the properties
of some control or section on the form). One way to get to the form's
properties is to right mouseclick the little square box at the upper
left intersection of the rulers in design view, and select Properties.

John W. Vinson[MVP]
 
Ah-ha... that was it. I was getting the option, not the form properties.
That answered that question. Now for the next one:

The form name is PPR_TrackingForm
The first option group is CustomerNotified1
The field I am trying to show/hide based on the option group is DateNotifed1

When I put in the code:
If PPR_TrackingForm!CustomerNotified1 = 1 Then
PPR_TrackingForm!NotifiedDate1.Visible = True
'PPR_TrackingForm!NotifiedDate1.enabled=true
Else: PPR_TrackingForm!NotifiedDate1.Visible = False
'PPR_TrackingForm!NotificationDate1.enabled=false
End If

I get an error of "Run-time error 424, Object required". I don't do
programming (haven't since the class I took in college in 94) and I have no
idea what this is trying to tell me. It gives me the option to debug & the
debugger shows the first line high-lighted when I open it. I am sure this is
something else I am doing (or not doing that I should), but I sure can't
figure it out... Any help would be greatly appreciated.

TIA,
Ruth
 
If Forms!PPR_TrackingForm!CustomerNotified1 = 1 Then
Forms!PPR_TrackingForm!NotifiedDate1.Visible = True
Else
Forms!PPR_TrackingForm!NotifiedDate1.Visible = False
End If

or, shorter,

Forms!PPR_TrackingForm!NotifiedDate1.Visible = _
(Forms!PPR_TrackingForm!CustomerNotified1 = 1)



--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)
 
Doug,
I tried this code and got the following error:

Run-time error '438
Object doesn't support this property or method

You guys are great to try to help me out like you are, I just wish I were
smart enough for the light-bulb to come on... Is there a easier way to get
these results other than programming? (I think I see a programming class in
the near future, otherwise)
 
Which line of code is it complaining about when you get the error?

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)
 
iamrdbrown said:
It was on the 1st line.

Is NotifiedDate1 the name of the *field* or the name of the *control*?
Controls have a visible property. Fields do not.
 
I have both the control and the field named the same: NotifiedDate1. This
was done in an effort to help me know which field goes with which control
when I started working on this issue.
 
I always rename my controls by putting txt in front if it's a text box, cbo
if it's a combo box and so on. So field NotifiedDate1 would be displayed in
text box txtNotifiedDate1. Yes, it's a pain to have to type all those extra
characters, but I find it's worth it.
 
Back
Top