Trouble with Access 2010 .SetFocus command syntax
up vote
0
down vote
favorite
Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
ms-access error-handling null syntax-error setfocus
asked Nov 7 at 13:45
Bughater
35
add a comment |
up vote
0
down vote
favorite
Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
ms-access error-handling null syntax-error setfocus
asked Nov 7 at 13:45
Bughater
35
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
ms-access error-handling null syntax-error setfocus
asked Nov 7 at 13:45
Bughater
35
Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
ms-access error-handling null syntax-error setfocus
ms-access error-handling null syntax-error setfocus
asked Nov 7 at 13:45
Bughater
35
asked Nov 7 at 13:45
Bughater
35
asked Nov 7 at 13:45
Bughater
35
asked Nov 7 at 13:45
Bughater
35
asked Nov 7 at 13:45
Bughater
35
35
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
answered Nov 7 at 13:50
Minty
1,4821411
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
add a comment |
up vote
0
down vote
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
answered Nov 7 at 15:04
Zebulan
1
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
answered Nov 7 at 13:50
Minty
1,4821411
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
add a comment |
up vote
0
down vote
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
answered Nov 7 at 13:50
Minty
1,4821411
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
add a comment |
up vote
0
down vote
up vote
0
down vote
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
answered Nov 7 at 13:50
Minty
1,4821411
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
answered Nov 7 at 13:50
Minty
1,4821411
answered Nov 7 at 13:50
Minty
1,4821411
answered Nov 7 at 13:50
Minty
1,4821411
answered Nov 7 at 13:50
Minty
1,4821411
1,4821411
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
add a comment |
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
Thanks, but the focus is still on a command button which starts the procedure where the error happens (Me.ActiveControl.Name verified). As I later got another unexplainable error error which might be related to the same procedure, I suspect a compiler failure and will delete the whole form module and paste the commands in a new one from a text editor (something which sometime helped in the past)! Note that I use Access 2010 ×64 - known to have some never fixed bugs.
– Bughater
Nov 8 at 16:15
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
What you are describing sounds like possible form corruption which unfortunately is not unique to any version of access, however your initial description said you set focus to the control, then are trapping an error on it, so what is the actual code used to open the form where the error occurs?
– Minty
Nov 8 at 16:33
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
Likely it was form (code) corruption indeed. I deleted some procedures and rewrote others, the problematic lines are no more there.
– Bughater
Nov 10 at 19:37
add a comment |
up vote
0
down vote
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
answered Nov 7 at 15:04
Zebulan
1
add a comment |
up vote
0
down vote
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
answered Nov 7 at 15:04
Zebulan
1
add a comment |
up vote
0
down vote
up vote
0
down vote
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
answered Nov 7 at 15:04
Zebulan
1
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)
answered Nov 7 at 15:04
Zebulan
1
answered Nov 7 at 15:04
Zebulan
1
answered Nov 7 at 15:04
Zebulan
1
answered Nov 7 at 15:04
Zebulan
1
1
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53190703%2ftrouble-with-access-2010-setfocus-command-syntax%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
