DoCmd.DoMenuItem acFormBar, 0, 4, , acMenuVer20
Hello Experts,
Here I am again supporting this legacy 2.0 code again.
DoCmd.DoMenuItem acFormBar, 0, 4, , acMenuVer20
This command is in the OnExit event of a textbox right before a Sendkeys "{F2}" command (which fires the AutoKey for "NextRecord")
I learned that this command runs the Access 2.0 toolbar's leftmost toolbar option and the 4th selection on that. The leftmost option is FILE and the 4th selection on it is SAVE AS.
The result is an invisible saving of the current record before going to the next record. (Why? I don't know. I thought the record would be saved automatically, and it appears to be when I REM out the command, but the designer is very talented, and he didn't put it in here for fun, so I have to assume it is in response to a problem with losing data when leaving the current record - no armchair quarterbacking here)
I also know that whenever it executes, it turns off the NumLock key so the user has to turn it back on to continue entering data. (now, that's what I call a "bug"!)
I determined that it is definitely this command (not the SendKeys) that is the culprit.
So, I tried replacing this with
DoCmd.Save
but that locks up the system while the whole thing saves, not just the current record.
Anybody have a method that will replace this and save the record without causing a full-on Save action slowdown?
Thanks,
Mac
Here I am again supporting this legacy 2.0 code again.
DoCmd.DoMenuItem acFormBar, 0, 4, , acMenuVer20
This command is in the OnExit event of a textbox right before a Sendkeys "{F2}" command (which fires the AutoKey for "NextRecord")
I learned that this command runs the Access 2.0 toolbar's leftmost toolbar option and the 4th selection on that. The leftmost option is FILE and the 4th selection on it is SAVE AS.
The result is an invisible saving of the current record before going to the next record. (Why? I don't know. I thought the record would be saved automatically, and it appears to be when I REM out the command, but the designer is very talented, and he didn't put it in here for fun, so I have to assume it is in response to a problem with losing data when leaving the current record - no armchair quarterbacking here)
I also know that whenever it executes, it turns off the NumLock key so the user has to turn it back on to continue entering data. (now, that's what I call a "bug"!)
I determined that it is definitely this command (not the SendKeys) that is the culprit.
So, I tried replacing this with
DoCmd.Save
but that locks up the system while the whole thing saves, not just the current record.
Anybody have a method that will replace this and save the record without causing a full-on Save action slowdown?
Thanks,
Mac
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Oops, I take it back. The NumLock still goes off.
Mac
Mac
ASKER
Oh, man...It toggles!
One time it goes off, the next time it goes on.
I'll get back to you when I figure it out.
Thanks for the command!
Mac
One time it goes off, the next time it goes on.
I'll get back to you when I figure it out.
Thanks for the command!
Mac
Happy to help you MacRena.
Regards,
Paasky
Regards,
Paasky
ASKER
paasky,
It was not the Access2.0 DoMenuItem command. I was wrong. It WAS the SendKeys command.
For some reason the SendKeys ("tab") was toggling on and off the NumLock every time the Procedure ran.
So I put in the following command to purposely turn NumLock off so the ("tab") will now always turn it On.
SendKeys ("NumLock")
BTW. That needs to be BEFORE the ("tab") because it doesn't execute when the ("tab") sends the focus to another control. I never would have thought that a procedure would not finish executing when that SendKeys ("tab") is there, but that's what it looks like. It almost acts like an Exit Sub.
Now, a followup question, if I may...
Where is there a list of the equivalent DoCmd.RunCommand replacements for the DoMenuItem commands?
I don't find it in Help or the KB.
Thanks,
Mac
It was not the Access2.0 DoMenuItem command. I was wrong. It WAS the SendKeys command.
For some reason the SendKeys ("tab") was toggling on and off the NumLock every time the Procedure ran.
So I put in the following command to purposely turn NumLock off so the ("tab") will now always turn it On.
SendKeys ("NumLock")
BTW. That needs to be BEFORE the ("tab") because it doesn't execute when the ("tab") sends the focus to another control. I never would have thought that a procedure would not finish executing when that SendKeys ("tab") is there, but that's what it looks like. It almost acts like an Exit Sub.
Now, a followup question, if I may...
Where is there a list of the equivalent DoCmd.RunCommand replacements for the DoMenuItem commands?
I don't find it in Help or the KB.
Thanks,
Mac
Sendkeys ("Numlock") will send keypresses N+u+m+l+o+c+k
Sendkeys "{NUMLOCK}",True
will cause Numlock keypress
Sendkeys "{TAB}",True
will cause Tabulator keypress
About equivalent DoCmd.RunCommand replacements for the DoMenuItem commands:
I did some detective work and after some time I found you link you might find *very* useful:
http://home.clara.net/tkwickenden/
There you can find detailed explanation about RunCommand Constants plus lots of other information and examples how to use them.
Regards,
Paasky
ASKER
paaskey,
Thanks for that GREAT link!
Here is the code that I added SendKeys {"NumLock") to - it works to eliminate the "bug" caused by the SendKeys{"tab"}.
Private Sub Comment_KeyPress(keyascii As Integer)
If keyascii = 13 Then
If NumEnter = 0 Or NumEnter = 1 Then
NumEnter = NumEnter + 1
Else
NumEnter = 0
' The SendKeys "{tab}" caused the NumLock to toggle off or on, so I added SendKeys "{NumLock}"
' to turn it off right before the "{tab}" thereby negating the bug's effect.
' (for some reason it must be before the "{tab}" or it doesn't do it. (3/15/2000)
SendKeys "{NumLock}"
SendKeys "{tab}"
DoEvents
End If
End If
End Sub
Thanks for that GREAT link!
Here is the code that I added SendKeys {"NumLock") to - it works to eliminate the "bug" caused by the SendKeys{"tab"}.
Private Sub Comment_KeyPress(keyascii As Integer)
If keyascii = 13 Then
If NumEnter = 0 Or NumEnter = 1 Then
NumEnter = NumEnter + 1
Else
NumEnter = 0
' The SendKeys "{tab}" caused the NumLock to toggle off or on, so I added SendKeys "{NumLock}"
' to turn it off right before the "{tab}" thereby negating the bug's effect.
' (for some reason it must be before the "{tab}" or it doesn't do it. (3/15/2000)
SendKeys "{NumLock}"
SendKeys "{tab}"
DoEvents
End If
End If
End Sub
I'm curious to know what's the purpose of this, could you explain me the background of this, please.
I interpret it works like this:
When the user press <Return> key, the variable (Control?) NumEnter increases by one if its current value is 0 or 1. Otherwise it moves cursor to next field.
What happens if you put the both keypresses into same Sendkeys line:
SendKeys "{NUMLOCK}{TAB}"
Also you could add ",True" in Sendkeys function that it executes keypress and doesn't let code run further until the keypress has done the action.
SendKeys "{NUMLOCK}{TAB}", True
Regards,
Paasky
I interpret it works like this:
When the user press <Return> key, the variable (Control?) NumEnter increases by one if its current value is 0 or 1. Otherwise it moves cursor to next field.
What happens if you put the both keypresses into same Sendkeys line:
SendKeys "{NUMLOCK}{TAB}"
Also you could add ",True" in Sendkeys function that it executes keypress and doesn't let code run further until the keypress has done the action.
SendKeys "{NUMLOCK}{TAB}", True
Regards,
Paasky
I think I got the idea, you have a memo which you want user to add maximum two lines of text and then focus move to next control... right?
I tried it with this code and it worked okay without {NUMLOCK}:
Private Sub Comment_KeyPress(KeyAscii As Integer)
If KeyAscii = vbKeyReturn Then
NumEnter = NumEnter - (NumEnter < 3)
If NumEnter = 2 Then
NumEnter = 0
SendKeys "{TAB}", True
End If
End If
End Sub
Paasky
I tried it with this code and it worked okay without {NUMLOCK}:
Private Sub Comment_KeyPress(KeyAscii As Integer)
If KeyAscii = vbKeyReturn Then
NumEnter = NumEnter - (NumEnter < 3)
If NumEnter = 2 Then
NumEnter = 0
SendKeys "{TAB}", True
End If
End If
End Sub
Paasky
ASKER
passky,
Yes, there is a textbox called "Comment" that the author designed to allow 2 lines of text before going to the next control (actually the OnExit event causes a new record, so it works with that to leave the last field on the form and start again at the top with a fresh record).
2 problems with your code.
First, it does not supress the NumLock Off bug.
Second, it doesn't accept 2 <Enter> KeyPresses before tabbing to the top.
I simply replaced the test with
If NumEnter = 3 Then...
to make it allow 2 <Enter> KeyStrokes, but it still toggles the NumLock.
I don't understand this line:
NumEnter = NumEnter - (NumEnter < 3)
Could you please describe what it does?
Thanks,
Mac
Yes, there is a textbox called "Comment" that the author designed to allow 2 lines of text before going to the next control (actually the OnExit event causes a new record, so it works with that to leave the last field on the form and start again at the top with a fresh record).
2 problems with your code.
First, it does not supress the NumLock Off bug.
Second, it doesn't accept 2 <Enter> KeyPresses before tabbing to the top.
I simply replaced the test with
If NumEnter = 3 Then...
to make it allow 2 <Enter> KeyStrokes, but it still toggles the NumLock.
I don't understand this line:
NumEnter = NumEnter - (NumEnter < 3)
Could you please describe what it does?
Thanks,
Mac
NumEnter = NumEnter - (NumEnter < 3)
is good example how to use Boolean Algebra:
If (NumEnter < 3) -> condition returns -1
NumEnter = NumEnter - (-1)
(which is same as NumEnter = NumEnter + 1)
if (NumEnter >=3) -> condition returns 0
NumEnter = NumEnter - (0)
Using these makes code shorter and optimized.
Paasky
is good example how to use Boolean Algebra:
If (NumEnter < 3) -> condition returns -1
NumEnter = NumEnter - (-1)
(which is same as NumEnter = NumEnter + 1)
if (NumEnter >=3) -> condition returns 0
NumEnter = NumEnter - (0)
Using these makes code shorter and optimized.
Paasky
ASKER
I see - that's very nice!
I would have expected a "Data type mismatch" if trying to add a True/False value to a math calculation, but I see the -1/0 is generated and accepted as numeric.
Thanks, paasky.
Mac
I would have expected a "Data type mismatch" if trying to add a True/False value to a math calculation, but I see the -1/0 is generated and accepted as numeric.
Thanks, paasky.
Mac
ASKER
I have no idea if that command does what the old one did, because I don't know why it was there.
The record seems to save without it, but it saves with your replacement, and it looks like it should be the correct replacement, so I guess that's that.
Access Help is very stupid when it comes to the acConstants. It lists them but doesn't describe their function (or does it, and I'm the stupid one???)
So, thanks for the help.
Mac