combo box control - which event

[mirandacascade]

I want to set things up such that a section of code will have been
executed by the time one clicks on the drop down arrow on a combo box
control. Currently, that section of code resides in the OnGetFocus
event of the combo box control, and this appears to work...I'm
guessing because one cannot click on the drop down arrow of a combo
box control without first having the combo box control receive focus.
But I noticed that the code gets fired when one clicks anywhere in the
combo box control...not just on the down arrow. That's not a problem,
but I'm wondering whether the code could reside in a different event
of the combo box control...an event that fires as one is clicking on
the down arrow...not just when one clicks somewhere in the control.
Is there such an event, and if so what is the name of the event?

Thank you.

[Bob Quintal]

mi************@yahoo.com wrote in
news:f6c16c2d-765b-41d9-a031-3b08aeab10f7
@e23g2000prf.googlegroups.co
m:

I want to set things up such that a section of code will have been
executed by the time one clicks on the drop down arrow on a combo
box control. Currently, that section of code resides in the
OnGetFocus event of the combo box control, and this appears to
work...I'm guessing because one cannot click on the drop down
arrow of a combo box control without first having the combo box
control receive focus. But I noticed that the code gets fired when
one clicks anywhere in the combo box control...not just on the
down arrow. That's not a problem, but I'm wondering whether the
code could reside in a different event of the combo box
control...an event that fires as one is clicking on the down
arrow...not just when one clicks somewhere in the control. Is
there such an event, and if so what is the name of the event?

Thank you.

You are using the best event available. The control's Enter event
occurs first, then the On Focus event. The mouseover event could be
used to determine if the cursor was above the down Arrow as opposed
to over the textbox area, but that's painful to code, subject to
timing errors (if the user moves the cursor quickly enough, the
event might be missed), and fires even if the down arrow is not
clicked requiring additional code..

My Curiosity has got the better of me, I cannot imagine a situation
where something needs doing when the user clicks to dropdown the
list that doesn't need doing when the user actually enters the
combobox, what are you doing when the user drops the list?


--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[lyle]

On Dec 26, 8:29 am, [e-mail] wrote:

I want to set things up such that a section of code will have been
executed by the time one clicks on the drop down arrow on a combo box
control.

It's too bad that the candidates for CDMA's 2007 "Strangest Request"
prize have already been selected. Shall we consider this for 2008?

[Wayne Gillespie]

On Wed, 26 Dec 2007 06:47:51 -0800 (PST), lyle <ly************@gmail.comwrote:

>On Dec 26, 8:29 am, [e-mail] wrote:

>I want to set things up such that a section of code will have been
executed by the time one clicks on the drop down arrow on a combo box
control.

It's too bad that the candidates for CDMA's 2007 "Strangest Request"
prize have already been selected. Shall we consider this for 2008?

But Lyle, it is to the strangest requests that you often supply the most
intriguing suggestions. :)
Wayne Gillespie
Gosford NSW Australia

[mirandacascade]

On Dec 26, 5:06*am, Bob Quintal <[e-mail]:

My Curiosity has got the better of me, I cannot imagine a situation
where something needs doing when the user clicks to dropdown the
list that doesn't need doing when the user actually enters the
combobox, what are you doing when the user drops the list?

1) The answer to the "...what are you doing..." question is that the
code is re-building the contents of the drop-down list and invoking
the Requery method of the combo box control

2) Disclaimer: relative newbie to the set of events that may happen on
a form with a combo box control, so the reasons listed below may very
well be without any merit. The reasons for the question are:

a) because preceding events could have changed the state, need to have
the capability to re-build the contents of the drop-down list
b) clicking on the drop-down arrow of the combo box control appears to
be an unambiguous signal by the user that he/she wishes to view the
contents of the drop-down list
c) arriving at the control (i.e. an OnGetFocus event) may not
necessarily be a signal by the user that he/she wishes to view the
contents of the drop-down lsit. For example, one can arrive at the
control by inadvertantly clicking in the control somewhere other than
the drop-down arrow. Or, perhaps if a user is tabbing through the
controls on the form, one may tab into this control without any
intention of doing anything on that control.
d) if possible, would prefer to re-build the contents of the drop-down
list and then issue the Requery method of the control only when there
is an unambiguous signal that the user wants to see the list.

[Thelma Roslyn Lubkin]

mi************@yahoo.com wrote:
: On Dec 26, 5:06*am, Bob Quintal <[e-mail]:
: a) because preceding events could have changed the state, need to have
: the capability to re-build the contents of the drop-down list
: b) clicking on the drop-down arrow of the combo box control appears to
: be an unambiguous signal by the user that he/she wishes to view the
: contents of the drop-down list

You also have the option of requerying the combobox after any
update event that changes its contents. That would mean that
the requery is only performed when the combo's drop-down list
actually changes: on the other hand, it is then performed even
if the user never accesses the combobox.

--thelma

[lyle]

On Dec 26, 11:08 am, [e-mail] wrote:

On Dec 26, 5:06 am, Bob Quintal <[e-mail]:

My Curiosity has got the better of me, I cannot imagine a situation
where something needs doing when the user clicks to dropdown the
list that doesn't need doing when the user actually enters the
combobox, what are you doing when the user drops the list?

1) The answer to the "...what are you doing..." question is that the
code is re-building the contents of the drop-down list and invoking
the Requery method of the combo box control

2) Disclaimer: relative newbie to the set of events that may happen on
a form with a combo box control, so the reasons listed below may very
well be without any merit. The reasons for the question are:

a) because preceding events could have changed the state, need to have
the capability to re-build the contents of the drop-down list
b) clicking on the drop-down arrow of the combo box control appears to
be an unambiguous signal by the user that he/she wishes to view the
contents of the drop-down list
c) arriving at the control (i.e. an OnGetFocus event) may not
necessarily be a signal by the user that he/she wishes to view the
contents of the drop-down lsit. For example, one can arrive at the
control by inadvertantly clicking in the control somewhere other than
the drop-down arrow. Or, perhaps if a user is tabbing through the
controls on the form, one may tab into this control without any
intention of doing anything on that control.
d) if possible, would prefer to re-build the contents of the drop-down
list and then issue the Requery method of the control only when there
is an unambiguous signal that the user wants to see the list.

It seems that keeping things simple has gone out of fashion here in
CDMA. I'll remain out of step by suggesting that when one of the
"preceding events [that] could have changed the state" occurs, the
Combo Box be re-queried, or otherwise provisioned/manipulated.
If I were hung up on "an unambiguous signal that the user wants to see
the list" I expect that I would create a button with the caption,
"SHOW ME THE REDHEADS" and in its On Click event I would re-query the
combo box and change its visibility property from false to true. But I
doubt that I would be (hung up).
After a million or so years of experimenting with setting states of an
Access Form and/or its Controls (over and beyond the default actions)
based on mouse position or activity I have concluded that Access Forms
are not HTML Forms, that is they don't lend themselves to this
approach. One reason is that if activity occurs quickly, the Access
Form and its Controls may not recognize it, and another is the cloying
synchronicity of VBA.

[Bob Quintal]

[Comments in-line]
mi************@yahoo.com wrote in
news:16**********************************@d4g2000p rg.googlegroups.com
:

On Dec 26, 5:06*am, Bob Quintal <[e-mail]:

>My Curiosity has got the better of me, I cannot imagine a
situation where something needs doing when the user clicks to
dropdown the list that doesn't need doing when the user actually
enters the combobox, what are you doing when the user drops the
list?

1) The answer to the "...what are you doing..." question is that
the code is re-building the contents of the drop-down list and
invoking the Requery method of the combo box control

The combobox needs the current data if the auto-complete feature is
turned on. or limit to list is set, even if typing directly into the
textbox portion Deferring the requery until the user activates the
dropdown destroys the functionality of the combobox..

This is why I was asking.why you want to wait until the dropdown is
clicked. It does not serve very well. Thelma's and Lyle's comments
about triggering the requery after the update of any other cortrol that
set parameters for the combobox are excellent advice to follow.

2) Disclaimer: relative newbie to the set of events that may
happen on a form with a combo box control, so the reasons listed
below may very well be without any merit. The reasons for the
question are:

a) because preceding events could have changed the state, need to
have the capability to re-build the contents of the drop-down list

Yes, but the after update events of those states are the logical place
to trigger the requery..

b) clicking on the drop-down arrow of the combo box control
appears to be an unambiguous signal by the user that he/she wishes
to view the contents of the drop-down list

This is true, but the data returned by the query may be required prior
to triggering the dropdown

c) arriving at the control (i.e. an OnGetFocus event) may not
necessarily be a signal by the user that he/she wishes to view the
contents of the drop-down lsit. For example, one can arrive at
the control by inadvertantly clicking in the control somewhere
other than the drop-down arrow. Or, perhaps if a user is tabbing
through the controls on the form, one may tab into this control
without any intention of doing anything on that control.

true.

d) if possible, would prefer to re-build the contents of the
drop-down list and then issue the Requery method of the control
only when there is an unambiguous signal that the user wants to
see the list.

Why? Does your query take too long to execute? If it does, maybe
something is sub-optimal in the query or the filter that causes it to
run too slowly. Adding indices to the underlying tables, and/or other
things can correct the problem at the source, rather than applying a
partially effective band-aid over the problem.
--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[Rick Brandt]

Bob Quintal wrote:

The combobox needs the current data if the auto-complete feature is
turned on. or limit to list is set, even if typing directly into the
textbox portion Deferring the requery until the user activates the
dropdown destroys the functionality of the combobox..

I have used the GotFocus event to requery ComboBox RowSources in numerous
situations and it has always worked just fine for me. Yes, an event that fired
upon actually dropping the list would be better, but since no such event exists
we use what is available.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[David W. Fenton]

lyle <ly************@gmail.comwrote in
news:7b**********************************@21g2000h sj.googlegroups.com
:

After a million or so years of experimenting with setting states
of an Access Form and/or its Controls (over and beyond the default
actions) based on mouse position or activity I have concluded that
Access Forms are not HTML Forms, that is they don't lend
themselves to this approach. One reason is that if activity occurs
quickly, the Access Form and its Controls may not recognize it,
and another is the cloying synchronicity of VBA.

I think that kind of thing is vastly overrated in HTML, too. The
MouseOver events in HTML are an abomination caused by people's
failure to use the default provisions for indicating clickability.
Microsoft did the same thing with its toolbars, replacing 3D buttons
with flat buttons with MouseOver events that made them 3D again,
because, er, um, because, um, well, it makes them look cool?

Back in the day when CSS wasn't practical, I guess it was kind of a
pain with relatively ugly websites. But CSS has been practical for a
very long time and gives more than adequate control over the
appearance of your clickable links, so the justification for
avoiding built-in capabilities and replacing them with complex
effects has long since vanished.

MouseOver events are not something I use very often at all in
Access. I just can't see how they add much to the kinds of apps I
am hired to build.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Rick Brandt]

David W. Fenton wrote:

lyle <ly************@gmail.comwrote in
news:7b**********************************@21g2000h sj.googlegroups.com

After a million or so years of experimenting with setting states
of an Access Form and/or its Controls (over and beyond the default
actions) based on mouse position or activity I have concluded that
Access Forms are not HTML Forms, that is they don't lend
themselves to this approach. One reason is that if activity occurs
quickly, the Access Form and its Controls may not recognize it,
and another is the cloying synchronicity of VBA.

I think that kind of thing is vastly overrated in HTML, too. The
MouseOver events in HTML are an abomination caused by people's
failure to use the default provisions for indicating clickability.
Microsoft did the same thing with its toolbars, replacing 3D buttons
with flat buttons with MouseOver events that made them 3D again,
because, er, um, because, um, well, it makes them look cool?

Back in the day when CSS wasn't practical, I guess it was kind of a
pain with relatively ugly websites. But CSS has been practical for a
very long time and gives more than adequate control over the
appearance of your clickable links, so the justification for
avoiding built-in capabilities and replacing them with complex
effects has long since vanished.

MouseOver events are not something I use very often at all in
Access. I just can't see how they add much to the kinds of apps I
am hired to build.

MouseOver and MouseOff events in web pages are very useful. The MouseMove event
that Access has is the one that is a waste of time. If it actually had the two
events that web pages provide then that could be useful.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[lyle]

On Dec 27, 3:24 pm, "David W. Fenton" <[e-mail]>
wrote:

Back in the day when CSS wasn't practical, I guess it was kind of a
pain with relatively ugly websites. But CSS has been practical for a
very long time and gives more than adequate control over the
appearance of your clickable links, so the justification for
avoiding built-in capabilities and replacing them with complex
effects has long since vanished.

MouseOver was useful but I don't use it much (at all?) anymore for the
reasons you state. CSS gives me enough pizazz.

MouseOver events are not something I use very often at all in
Access. I just can't see how they add much to the kinds of apps I
am hired to build.

I have told a few young enthusiaticians that an Access application
that looks and acts like a WII (Nintendo not World War II) adventure
is not necessarily a great Access application.

[Bob Quintal]

"Rick Brandt" <ri*********@hotmail.comwrote in
news:mt*******************@newssvr12.news.prodigy. net:

Bob Quintal wrote:

>The combobox needs the current data if the auto-complete feature
is turned on. or limit to list is set, even if typing directly
into the textbox portion Deferring the requery until the user
activates the dropdown destroys the functionality of the
combobox..

I have used the GotFocus event to requery ComboBox RowSources in
numerous situations and it has always worked just fine for me.
Yes, an event that fired upon actually dropping the list would be
better, but since no such event exists we use what is available.

Well like I said before, if you don't use the limit to list feature,
and do not use the auto-completion feature, then it might make sense
to have an On Dropdown event.

But since in all the time I've been using Access, I use at least one
of those two features, it would be totally useless. I suppose the
crew at MS thought the same.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.comwrote in
news:jH***************@newssvr25.news.prodigy.net:

MouseOver and MouseOff events in web pages are very useful.

For what?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/