By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,558 Members | 1,177 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,558 IT Pros & Developers. It's quick & easy.

How to control unexpected/unwanted GotFocus event property setting (expression)

P: n/a
MLH
A form named frmVehicleEntryForm has a number of textbox
controls who's OnGotFocus property setting is an expression...
=Change2Green()

Change2Green() looks something like this...
Dim MyControl As Control
Set MyControl = Screen.ActiveControl
MyControl.BackColor = 65280

Tabbing from control-to-control is great. Each time I land on
a control, its background turns green making it friendly to use.
LostFocus property setting turns them back to white.

The undesirable behavior is this. I have one control whose dbl-clik
event makes frmVehicleEntryFrom.Visible false and opens another
little Owner Entry Form. When the owner entry form closes and
frmVehicleEntryFrom.Visible is set to True, the form's OwnerID
textbox control (that had the focus when form went invisible)
gets its OnGotFocus event again (dunno how???) and Access 97
complains with a 2474 error, moaning something to the effect that the
"expression I entered requires the control to be in the active
window". What the hell can that possibly mean?

I have verified for sure that the error emanates from running
the above named procedure on that control and that form.
It just happens upon returning to the form. Have no idea why.
The vehicle entry form does not appear to be selected when
the owner entry form closes and the vehicle entry form opens.
Everything looks normal and all is sort-a-paused like its waiting
on me to do something on the form. But when I click on the form
(anywhere) the 2474 error barks out.

I just have to OK the error msg and all goes back to normal.
But its annoying and my target audience isn't gonna wanna
see that msg. Suggestions?
Nov 13 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Tue, 07 Jun 2005 23:49:10 -0400, MLH <CR**@NorthState.net> wrote:

Put this as the first line of the ChangeToGreen procedure:
On Error Resume Next 'don't want to hear about possible 2474 error.

The reason OnGotFocus fires again because that control is gaining
focus again - after it was somewhere in OwnerEntryForm.

Adding cuteness to an Access application costs a lot of time. Focus on
functionality.

-Tom.

A form named frmVehicleEntryForm has a number of textbox
controls who's OnGotFocus property setting is an expression...
=Change2Green()

Change2Green() looks something like this...
Dim MyControl As Control
Set MyControl = Screen.ActiveControl
MyControl.BackColor = 65280

Tabbing from control-to-control is great. Each time I land on
a control, its background turns green making it friendly to use.
LostFocus property setting turns them back to white.

The undesirable behavior is this. I have one control whose dbl-clik
event makes frmVehicleEntryFrom.Visible false and opens another
little Owner Entry Form. When the owner entry form closes and
frmVehicleEntryFrom.Visible is set to True, the form's OwnerID
textbox control (that had the focus when form went invisible)
gets its OnGotFocus event again (dunno how???) and Access 97
complains with a 2474 error, moaning something to the effect that the
"expression I entered requires the control to be in the active
window". What the hell can that possibly mean?

I have verified for sure that the error emanates from running
the above named procedure on that control and that form.
It just happens upon returning to the form. Have no idea why.
The vehicle entry form does not appear to be selected when
the owner entry form closes and the vehicle entry form opens.
Everything looks normal and all is sort-a-paused like its waiting
on me to do something on the form. But when I click on the form
(anywhere) the 2474 error barks out.

I just have to OK the error msg and all goes back to normal.
But its annoying and my target audience isn't gonna wanna
see that msg. Suggestions?


Nov 13 '05 #2

P: n/a
MLH
Yes, that did the trick.

Put this as the first line of the ChangeToGreen procedure:
On Error Resume Next 'don't want to hear about possible 2474 error.

The reason OnGotFocus fires again because that control is gaining
focus again - after it was somewhere in OwnerEntryForm.

Adding cuteness to an Access application costs a lot of time. Focus on
functionality.

-Tom.

A form named frmVehicleEntryForm has a number of textbox
controls who's OnGotFocus property setting is an expression...
=Change2Green()

Change2Green() looks something like this...
Dim MyControl As Control
Set MyControl = Screen.ActiveControl
MyControl.BackColor = 65280

Tabbing from control-to-control is great. Each time I land on
a control, its background turns green making it friendly to use.
LostFocus property setting turns them back to white.

The undesirable behavior is this. I have one control whose dbl-clik
event makes frmVehicleEntryFrom.Visible false and opens another
little Owner Entry Form. When the owner entry form closes and
frmVehicleEntryFrom.Visible is set to True, the form's OwnerID
textbox control (that had the focus when form went invisible)
gets its OnGotFocus event again (dunno how???) and Access 97
complains with a 2474 error, moaning something to the effect that the
"expression I entered requires the control to be in the active
window". What the hell can that possibly mean?

I have verified for sure that the error emanates from running
the above named procedure on that control and that form.
It just happens upon returning to the form. Have no idea why.
The vehicle entry form does not appear to be selected when
the owner entry form closes and the vehicle entry form opens.
Everything looks normal and all is sort-a-paused like its waiting
on me to do something on the form. But when I click on the form
(anywhere) the 2474 error barks out.

I just have to OK the error msg and all goes back to normal.
But its annoying and my target audience isn't gonna wanna
see that msg. Suggestions?


Nov 13 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.