Re: combo box control - which event

mirandacascade@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

combo box control - which event

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.

Re: combo box control - which event

On Dec 26, 8:29 am, mirandacasc...@yahoo.com 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?

Re: combo box control - which event

On Wed, 26 Dec 2007 06:47:51 -0800 (PST), lyle wrote:

>On Dec 26, 8:29 am, mirandacasc...@yahoo.com 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

Re: combo box control - which event

On Dec 26, 5:06=A0am, Bob Quintal wrote:
> 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.

Re: combo box control - which event

mirandacascade@yahoo.com wrote:
: On Dec 26, 5:06 am, Bob Quintal wrote:
: 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

Re: combo box control - which event

On Dec 26, 11:08 am, mirandacasc...@yahoo.com wrote:
> On Dec 26, 5:06 am, Bob Quintal wrote:
>
> > 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.

Re: combo box control - which event

[Comments in-line]
mirandacascade@yahoo.com wrote in
news:16d89f30-84fc-4044-96f1-792093cf73dd@d4g2000prg.googleg roups.com
:

> On Dec 26, 5:06 am, Bob Quintal wrote:
>> 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

Re: combo box control - which event

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

Re: combo box control - which event

lyle wrote in
news:7bf8a533-9525-4e04-bda4-308e1bc4b381@21g2000hsj.googleg roups.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/

Re: combo box control - which event

David W. Fenton wrote:
> lyle wrote in
> news:7bf8a533-9525-4e04-bda4-308e1bc4b381@21g2000hsj.googleg roups.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

Re: combo box control - which event

On Dec 27, 3:24 pm, "David W. Fenton"
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.

Re: combo box control - which event

"Rick Brandt" wrote in
news:mtScj.81504$Um6.28985@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

Re: combo box control - which event

"Rick Brandt" wrote in
news:jHUcj.817$pA7.427@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/