Cycle Property = Current Page skips TabStop 0

[rubbernilly]

Just wondering if someone else has noticed this, or if there is something I'm missing.

I have a multi-page form in Access (using the PageBreak control and navigation buttons to go to 'Next' and 'Previous' pages). I set the Form's Cycle property to be "Current Page".

That works great to the user from tabbing from the last control on one page of the form and landing on the first control of the next page of the form (which would make the form controls incrementally creep/roll up the form).

Here's the problem: when the tab passes from the last control on the page and begins its cycle again, it doesn't go to the control with TabStop = 0. It goes to the control with the TabStop = 1. I can immediately Shift+Tab, and it DOES go to the TabStop 0 control, so I know it is a valid TabStop target.

In fact, I have confirmed that it isn't a problem with the control itself (and created a workaround) by having an invisible control with a TabStop of 0, so that the first visible control has a TabStop of 1. The invisible control can never receive the focus, and the Tab behavior performs as expected after the form cycles from the last control on the page back to the first.

Anyone else have that problem?

I have Access 2016.

 

[Darrylles]

Check the form VBA module, does it have: 'OPTION BASE 1' statement?
If not, (not sure if this is possible), but - do you have a global VBA module with this statement in it?

https://msdn.microsoft.com/en-us/library/aa266179(v=vs.60).aspx

ATB,

Darrylle

 

[rubbernilly]

Unfortunately, that is not what is happening. There is no such Option Base statement anywhere, and I verified that the expected base is still the expected 0 by dimensioning an array and filling members starting at 0.

I've recreated the issue in a small example database (Access 2016 format)... it should be attached.

To see the problem, open the form and tab through the controls. Once you hit the last control on the page, you should return to the first field, but you go to the second. If, when you get there, you then hit Shift+Tab to step backward through the Tab Order, you will go to the first field again.

Only the first page of the form has the problem, probably because the controls on the subsequent pages start their TabIndex at something greater than 0.

Does that help demonstrate the issue?

 

[combo]

It's frustrating, but one can add control with index 0, hide it and switch off its tab key behaviour.

combo

 

[rubbernilly]

Yep, you can see in the first post that's what I did. I just wondered if anyone else was having the same issue.

 

[combo]

I missed that. Seems that ms has problems with consistent base definition. A good thing in 2016 is that they fixed field type definition in table, for some time only default or imported could be used.

combo