Combo Box, events and keyboard questions..

[Michel S.]

Hi !

I'm using Access XP and I'm experiencing the following problems with
the comboBox events:

1) If I make a selection in the drop down list using the cursor keys
followed by the enter key, the "After Update" event correctly fires and
my selection appears in the closed box.

From that event, I then set the focus to another field, a textbox.

Upon entering that field, it's "Key press" event fires and the Ascii
value is 13, which is the enter key I used to make my selection in the
combo. Since "Enter" is a valid entry in that specific textbox, I can
hardly disregard it in the text box keypress event.

Question: is there a way to sink that "enter" key before the next field
get its focus ? (Preferably within the combo code itself).


2) If I use my mouse to highlight a choice in the dropdown list and
then press "enter" to confim that selection, the dropdown list closes,
but the combo value stays to its old value.

Is this behavior normal ?


3) Once the combo box is exited (or loose focus ?), I want to assign
its value to a textbox, set the focus to that textbox and then hide the
combo.

For example, in the after update event, I use code like this :

Private Sub cbo_AfterUpdate()

Debug.Print "cbo after update"

With txt
.Value = cbo.Value
.Visible = True
.SetFocus
End With

cbo.Visible = False

Debug.Print "cbo after update exit"

End Sub

Tracing the events sequence in the immediate window, after selecting a
value with the mouse only, I find the following :

cbo after update
cbo exit
cbo enter
txt got focus
cbo after update exit
cbo change

Questions :

a) Why do the cbo Exit and cbo Enter fire in the middle of the after
update event ? Isn't the combo already the active control ?

b) Why are there no "cbo lost focus" or "cbo exit" events after the
text gets the focus ?

Thanks in advance !

 

[Allen Browne]

When you SetFocus to the text box, Access is still processing the events of
the combo. It doesn't complain, but it has to finish processing the events,
and so the focus silently returns to (or perhaps never leaves) the combo, so
the SetFocus is ineffective.

By all means, use the combo's AfterUpdate to set the value of the text box.
But use its LostFocus event to set focus to the text box.

That should also avoid the problem of the missing events.

 

[Michel S.]

Thanks for your answer..

The problem I see with your solution is that setting the focus to the
textbox only in the combo "lost focus" event requires that the combo
has actually lost the focus, which won't happen until the user moves to
another field or I do it myself in the code (which I curretly do in the
"after update" event).

After the textbox is updated with the combo change, I need to hide the
combo and show the textbox -- they are actually at the same position on
the form. But I can't hide the combo as long as it has the focus
that's where the problem lies.

According to google, this way of toggling between a textbox and a
combobox is often mentioned or suggested, but I still haven't found a
working code sample.

Thanks again !


Allen Browne vient de nous annoncer :

 

[Allen Browne]

Michael, what are you actually trying to achieve here?

Perhaps you can:
- Set the combo's TabStop to No (so it doesn't come into the picture when
tabing through the form's controls.)
- Put the combo behind the text box (Format | Send to back.)
- In the text box's Got Focus event, SetFocus to the combo.
- In the combo's AfterUpdate event, set the value of the text box.
No need to hide the combo: it just silently returns behind the text box once
it loses focus.

I'm not clear if that will achieve what you need.

 

[Michel S.]

Allen,

I'm working on a form which has more than 120 identical textboxes. The
form is used to record a jury's members decision details on candidates
presented to them. The decision is based on 10 different criteria.

Actually, the "form" is a continuous subform where 12 instances of the
10 criteria are shown.

Each textbox has the score for a criteria/juror pair, and can be one of
6 different values (the same for all fields).

In order to minimize the number of "down arrows" on the form, I was
asked to present them all as a textboxes and to change only the
"current" field to a combo box when the user double clicked on it and
reset it to a textbox asap.

In order to minimize the number of "hidden" combos, I defined only one
for the whole form, and in the double-click of the textbox event, I set
the combo coordinates to the textbox ones (as well as its value) before
making it visible.

Once the user makes a choice (or cancel the combo or goes to another
field), I have to switch back to the textbox and hide the combo until
the user double click on another field.

Hope this description helps..


Since the same combo is intended to be used behind all the 120
textboxes, I guess you understand why I can't use "as is" your
otherwise excellent suggestion, unless there's a way to acheive the
"Format | Send to back" at runtime in VBA.

Thanks again,
Michel


Allen Browne a formulé ce mercredi :

 

[Allen Browne]

Okay, so you are reusing one unbound combo 120 times.

It would seem to me that you want to use the Got Focus event of each text
box to set the Left and Top properties of the combo, SetFocus to it, and
record the text box it represents into a form-level variable. Then in the
AfterUpdate event of the combo, assign its value to that text box.

With the form open in design view, you can programmatically assign a generic
function call to the On Got Focus *property* of each text box. The function
call would accept the name of the textbox as an argument (since you have
that name anyway), so the generic function sets which text box the combo
should return values to.

The combo never needs to hide: it just turns up whereever you click or tab
to.

(Presumably this is just a 12 x 10 matrix of text boxes, and the data is
stored in a normalized way.)

 

[Michel S.]

Thanks Allen,

From what you say, I understand that there's no easy way to make the
combo "hide itself" after it has been updated; while it's not exactly
what I want, I think I can (have to ?) live with that.

FYI, I'm using a class module to handle all these controls events in a
single place. When the control is assigned to one class instance, the
class code takes care of the all event handling - enabling and sinking
them. It works well and is very easy to maintain.

And yes, the data *is* normalized. ;o)

Thanks again !


Allen Browne a présenté l'énoncé suivant :

 

[Allen Browne]

Whatever you think is best.

From what I understand, the combo should actually be visible when any one of
the 120 text boxes has focus.