Deleting entries in combo boxes

[Meirans-Mertens]

In a form (Access 97, Win98), I have a combo box that lists the names of
several properties. The combo box is labeled "Property" and relies on an
underlying lookup table called "Property Names." Users can pick a name in
the list OR they can type a new name (i.e., NewData). In the latter case, a
message appears telling them that the name is not in the list, and ask them
whether they want to add it to the list. If they click No, the new name is
not retained in the field and is not added to the list. If they click Yes,
the name is added to the lookup table and remains available for all
subsequent data entry. To perform this automation, I use a VB procedure that
I found years ago in an issue of "Inside MS Access" (December 1998). It is
attached to the "On Not in List" property of the combo box (located in the
Event Property Sheet). The code is reproduced below. My question is: Is it
possible to amplify this procedure so that, when users have selected a name
in the list and when they press the Delete key (or Ctrl+X), a message would
appear telling them that they are about to delete the name and ask them
whether they want to delete it from the list? If they click No, nothing
would happen, and if they clcik Yes, the name would effectively be deleted
from the underlying lookup table. Although the selected name would remain in
the field of previously entered data, it would not appear anymore in the
combo box. If this is possible, then what would be the code? Thanks in
advance for any input you might have. (One method to turn around this
problem is to access the lookup table and delete the selected name therein.
However, this method is not elegant and I'd rather avoid making tables
available to the users.)

Here's the code. It works nicely, facilitates data entry, and helps greatly
in reducing data entry errors such as mispellings, etc. If you want to use
it, you'll need to set the combo box's "Limit to List" property to Yes and
the "Locked" property to No (both are located in the Data Property Sheet).

Private Sub Property_NotInList(NewData As String, Response As Integer)
Dim rst As Recordset
Dim Msg As String
Dim UserResponse As Integer
Msg = NewData & " is not in the list." & vbCr & "Would you like to add it?"
UserResponse = MsgBox(Msg, vbYesNo + vbQuestion, "Please Verify")
If UserResponse = vbYes Then
Set rst = CurrentDb.OpenRecordset("Property Names")
With rst
.AddNew
![Property Name] = NewData
.Update
End With
Response = acDataErrAdded
rst.Close
Set rst = Nothing
Else
Response = acDataErrContinue
Me![Property].Undo
End If
End Sub

 

[Tim Ferguson]

My question is: Is it
possible to amplify this procedure so that, when users have selected a
name in the list and when they press the Delete key (or Ctrl+X), a
message would appear telling them that they are about to delete the
name and ask them whether they want to delete it from the list?

This is starting to ask a lot of a simple combo box: which is really only
there to make easy work of picking a thing from a list. Look how the other
hundred Windows apps you have on your PC use combo boxes, and ask yourself
if your users really need to have one app that does it completely
differently.

You might want to think about using a subform to manipulate the foreign
table: this will let you add and delete records with whatever prompts and
warnings you think appropriate, and won't necessarily look like something
your users already know about.

Hope that helps


Tim F

 

[Meirans-Mertens]

This is starting to ask a lot of a simple combo box: which is really only
there to make easy work of picking a thing from a list. Look how the other
hundred Windows apps you have on your PC use combo boxes, and ask yourself
if your users really need to have one app that does it completely
differently.

You might want to think about using a subform to manipulate the foreign
table: this will let you add and delete records with whatever prompts and
warnings you think appropriate, and won't necessarily look like something
your users already know about.

Hope that helps


Tim F

No, it doesn't help, but thank you for your time anyway. Allow me to add a
few points:

1. I somewhat agree that a combo box "is really only there to make easy work
of picking a thing from a list." However, it is not always possible to
include all the necessary data in a lookup table when one creates it. In
which case, it is certainly a plus for a user to add data in the underlying
table when the need arises, and to be able to do so directly from the user's
form.
2. Some people (namely, those who wrote the code I inserted in my original
message and who published it) found that to be able to add data to
the underlying table directly from the user's form would be useful and that
it would not really be doing things so "completely differently."
3. Since it is possible to add data to the underlying table directly from
the user's form, I don't see why it shouldn't be possible to delete data,
and I don't think that this is really "starting to ask a lot of a simple
combo box." Twenty or twenty-five years ago, people used to type commands at
the DOS prompt, and things were working fine that way. Would you say that
the demand for a
graphic interface and a mouse was too much to ask?
4. In my application, when a user selects a entry in the combo box, a
subform appears with information related to the selection. You will find,
maybe, that this is also "to ask a lot of a simple combo box," but I suppose
that there are always people who just look at the Everest and never wonder
what it would be like to climb it. Too much to ask, you see.
5. Finally, there are millions of PC users in the world and you can't
possibly know
everyone's needs, can you? Furthermore, it is not because hundreds of people
jump off a cliff that you should follow the same route. In this respect,
when you suggest to
"look how the other hundred Windows apps you have on your PC use combo
boxes, and ask yourself if your users really need to have one app that does
it completely differently," I would suggest in turn that you brush up your
Logic 101, perhaps, or that you purchase a book on logical fallacies.

I hope that this criticism will not bruise your ego too much and that you
will find it useful.

Friendly speaking,

Nicolas Mertens.

 

[Tim Ferguson]

2. Some people (namely, those who wrote the code I inserted in my
original message and who published it) found that to be able to add
data to the underlying table directly from the user's form would be
useful

No argument...

5. Finally, there are millions of PC users in the
world and you can't possibly know
everyone's needs, can you?

We can certainly predict some of them, though, and high on the list is
predictablity. WIMP GUIs are easy to use because the same things on screen
always do the same thing and react the same way. It's the script tarts and
the showoffs who undermine the user models and produce what is in the end
hard to use and demoralising software. For sure, you can make your combo
box sing and dance and juggle flaming axes, but just don't go to bed
thinking you've done a Good Thing.

B Wishes


Tim F

 

[Greg Kraushaar]

combo box." Twenty or twenty-five years ago, people used to type commands at

the DOS prompt, and things were working fine that way. Would you say that
the demand for a
graphic interface and a mouse was too much to ask?

Ahh, but Microsoft didn't try to make it look like a DOS session.
OS/2 did and where is that today ?

everyone's needs, can you? Furthermore, it is not because hundreds of people
jump off a cliff that you should follow the same route. In this respect,
when you suggest to

In your case, you are not following the hundreds of others who
followed, the path, but are jumping off the cliff instead

"look how the other hundred Windows apps you have on your PC use combo
boxes, and ask yourself if your users really need to have one app that does
it completely differently," I would suggest in turn that you brush up your
Logic 101, perhaps, or that you purchase a book on logical fallacies.

I suggest you brush up on your GUI design standards.
The point he was making was that Windows works because the same look
and feel applies to all Apps, well the successful one anyway.
There are official standards out there. The combo box adheres to them.
If you want something new, spend the time to learn C++ or Delphi,
develop the control and publish it. If it is seen as worhtwhile, It
will make you billions, and eventually replace the outdated combo box

I hope that this criticism will not bruise your ego too much and that you
will find it useful.

I am sure it does not bruise his ego, or mine. It does make me and
probably others add you to the ignore messages from... list
That gets you less help in the long runRegards Greg Kraushaar
Wentworth Falls Australia
(Do not email - the reply address is a Spam spoofer)
(If you really must, remove all UCase and numbers)

 

[Meirans-Mertens]

Thanks. Your comments are enlightening.
N.

Ahh, but Microsoft didn't try to make it look like a DOS session.
OS/2 did and where is that today ?


In your case, you are not following the hundreds of others who
followed, the path, but are jumping off the cliff instead


I suggest you brush up on your GUI design standards.
The point he was making was that Windows works because the same look
and feel applies to all Apps, well the successful one anyway.
There are official standards out there. The combo box adheres to them.
If you want something new, spend the time to learn C++ or Delphi,
develop the control and publish it. If it is seen as worhtwhile, It
will make you billions, and eventually replace the outdated combo box


I am sure it does not bruise his ego, or mine. It does make me and
probably others add you to the ignore messages from... list
That gets you less help in the long run
Regards Greg Kraushaar
Wentworth Falls Australia
(Do not email - the reply address is a Spam spoofer)
(If you really must, remove all UCase and numbers)

 

[Meirans-Mertens]

Thank you. It was an interesting session.
N.

No argument...


We can certainly predict some of them, though, and high on the list is
predictablity. WIMP GUIs are easy to use because the same things on screen
always do the same thing and react the same way. It's the script tarts and
the showoffs who undermine the user models and produce what is in the end
hard to use and demoralising software. For sure, you can make your combo
box sing and dance and juggle flaming axes, but just don't go to bed
thinking you've done a Good Thing.

B Wishes


Tim F