Behavior changed with upgrade to Access 2013 (1 Viewer)

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
I always turn to this forum when I need help--you guys are great and I thank you in advance for advice! A program upgrade from Access 2003 to 2013 has changed behavior in a client's payroll verification routine.

I have a control that gets the focus when the operator hits the enter key one too many times in her haste. The OnExit event for that control triggers several things including a requery of the total. When she gets there in error, she uses her mouse to return to the proper place in the entry table to continue entering. The problem is that the subform seems to be reloaded or requeried so that the pointer is at the first record and not where it was when the error occurred. I am therefore trying figure out a workaround. I want to be able to leave the control that was reached in error if I need to, without triggering the OnExit event. Is there a way?
 

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
... I want to be able to leave the control that was reached in error if I need to, without triggering the OnExit event. Is there a way?
Only if you can set up a rule/criteria from which you can determine that the control is reached in error!
Rule could be, missing value in one or more controls.
But in first place I would look at why she is hitting the Enter key to many times!
Is it because the form reached to slow, (she is in doubt it she hit the Enter key or not and press one time more), or ...?
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
JHB, I had to laugh at your question about why she hits enter too many times--if only you could meet her you would understand! Anyway, that is out of my control. Now I am trying to fix the problem by recording the current record number in a SaveN field in the footer of the subform. When the OnEnter event of the field (the one that was left inadvertantly) is triggered, I try to put the field selector of the subform back where it was. The macro:

Code:
if Nz([Forms]![pv]![verpwrk subform].[Form]![SaveN])<>0 then
   goto control [verpwrk subform]
   ...
   ...etc.
end if

I get the 2110 error: "Microsoft Access can't move the focus to the control verpwrk subform"

Obviously it is able to reference SaveN which is on the subform (which was properly updated with the proper record #). I have tried entering the full [forms]![pv]![verpwrk subform] but that doesn't work either.

Thanks
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 17:40
Joined
Sep 12, 2006
Messages
15,613
you might be able to use "absoluteposition" to store and restore the active record. I have to check the syntax each timer, but it's just a long number

something like this

savepos = me.absoluteposition
....
'restore it
me.absoluteposition = savepos
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
But it is storing the record # correctly--it just won't let me go to the control [verpwrk subform] to do the necessary findrecord step. In the snippet of code that I posted, it can see the saved record # in the if clause.
 

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
Post a stripped version of your database with some sample data + info about how to reproduce the error.
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
Thanks JHB. I won't have a chance to work up a sample until later today. Stay tuned!
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
Took some effort to get this sample code pared down. Thanks for taking a look at it. When open, click on Verify Piecework. Type 102114 Enter for date, then 9 Enter for the employee number. Next:
22 Enter Enter
10 then 5 Enters
--notice the record selector in the subform moves down
22 Enter Enter
20 then 5 Enters
--now follows the problem:
press Enter once more. This is the error, as it goes to the Applied % as though all of the piecework sheets have been entered. She mistakenly hit the Enter key once too many times. To get back to the first piecework entry field, she must use her mouse to get there. Notice it correctly saved the "3" in the footer of the subform, and if only it would let the control go to the subform, the macro should set the record selector back at 3.

This is probably clear as mud! There will be many piecework sheets with many figures to be entered for each of a couple hundred sewers--it takes her a while to find her place when she screws up. Would just be a neater package if the program could do it automatically. Really odd that 2003 version didn't move the record selector.
 

Attachments

  • sample.accdb
    1.8 MB · Views: 68

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
I've tried to do what you describe but ..
Type 22 (press Enter twice) then it moves to the "Price".
Type 10 (in "Price") then 5 Enters
then it moves to the control in which I just started typing 22.
So I do not experience what you describe as:
--notice the record selector in the subform moves down
-- as it goes to the Applied %
-- etc.
Maybe the client database setting is different:
Choose "File"->"Options"->"Client Settings", look at the setting for "Enter".
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 17:40
Joined
Sep 12, 2006
Messages
15,613
you could prevent the form moving off the current record, by setting the cycle property accordingly.

of course, then you need to learn a different way of moving to a new record. (not sure if there is a keyboard method when the cycle property is current record
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
JHB, it behaves properly up to the point you describe. Did you go through the list until you got to the point where you hit Enter a 6th time? Then had to use the mouse to move back up ? The enter key's behavior is proper. Moving from the Applied % field back to the first piecework field is where the problem is.
 

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
JHB, it behaves properly up to the point you describe. Did you go through the list until you got to the point where you hit Enter a 6th time? Then had to use the mouse to move back up ? The enter key's behavior is proper. Moving from the Applied % field back to the first piecework field is where the problem is.
I never come down in the Applied % field only by hitting the Enter key.
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
Well, I have tried it on several computers. If you don't enter 102114 for the date, you can't reproduce the error.
 

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
Yes you're right, with 102114 then I experience what you describe.
I'll not ask why it is set up like it is, (sorry - but for me it looks like a mess)! :D
When does the control ApPercent get focus when it should be right?
Could it be set up some rule for that, (controls which isn't filled, buttons not clicked etc.)?
Maybe also converting the Macro to an Event procedure could help, you've much more control over your program in an event procedure!
 

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
Of course, you are correct--it is a mess. I won't make excuses--It was written back in the '90's, then upgraded to 2003 version, and finally, with new computers, upgraded to 2013 version. Their payroll includes pieceworkers, home sewers, hourly workers, combinations of these, etc. (unbelievably complicated mess), but the program does give them the correct computations (I write better code these days). I hadn't been into it for years until this little problem cropped up, hindering the data entry clerk's speed. (All in the spirit of "if it ain't broke, don't fix it")! I only work for them as a contract programmer, and would guess their choice wouldn't be to pay to rewrite this.

I am pursuing it because I still don't know why I cannot "goto control [verpwrk subform]"? In answer to your question: The control Appercent gets the focus properly after all sheets of little piecework stickers have been entered, control returns for another entry, but the enter key is pressed when the field is blank.
 

JHB

Have been here a while
Local time
Today, 18:40
Joined
Jun 17, 2012
Messages
7,732
Edit:
Try it now, database attached.

I think the below is out of question now, (forget it).
..
In answer to your question: The control Appercent gets the focus properly after all sheets of little piecework stickers have been entered ...
No I mean, when .. (let say all data have been entered) what should people then do, which action should they do to tell the program now I've entered all data?

Sometimes you can't set focus to a other control, before ex. the after update have taken place, so it could really be a lot of cases you can't move focus!

Have you had any thoughts about the below?
Could it be set up some rule for that, (controls which isn't filled, buttons not clicked etc.)?
Maybe also converting the Macro to an Event procedure could help, you've much more control over your program in an event procedure!
 

Attachments

  • sampleel4.zip
    257.3 KB · Views: 38
Last edited:

ellenr

Registered User.
Local time
Today, 13:40
Joined
Apr 15, 2011
Messages
397
movelast doesn't get the job done, but your code helped greatly! What works is the following:

Private Sub T4_Enter()

If Me.verpwrk_subform.Form![SaveN] <> 0 Then
Me.verpwrk_subform.Form.Recordset.FindFirst "n = " _
& Me.verpwrk_subform.Form![SaveN]
End If
Me.verpwrk_subform.Form![SaveN] = 0
End Sub

Thank you for your perseverance, even if the whole screen made no sense to you!

Thank you!
 

Users who are viewing this thread

Top Bottom