• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 615
  • Last Modified:

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
0
MacRena
Asked:
MacRena
  • 7
  • 6
1 Solution
 
paaskyCommented:
Hello MacRena,

Save the record with
docmd.RunCommand acCmdSaveRecord    

Regards,
Paasky
0
 
MacRenaAuthor Commented:
Paasky,

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
0
 
MacRenaAuthor Commented:
Oops, I take it back.  The NumLock still goes off.
Mac
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
MacRenaAuthor Commented:
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
0
 
paaskyCommented:
Happy to help you MacRena.

Regards,
Paasky
0
 
MacRenaAuthor Commented:
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
0
 
paaskyCommented:

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
0
 
MacRenaAuthor Commented:
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
0
 
paaskyCommented:
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      
0
 
paaskyCommented:
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
0
 
MacRenaAuthor Commented:
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
0
 
paaskyCommented:
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
0
 
MacRenaAuthor Commented:
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
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now