Problem with access keys and tab controls in Access 2010
-
Monday, November 29, 2010 3:27 PM
I have an Access form that was created in Access 2003. It works fine in Access 2003 and 2007. With Access 2010 (still using the .mdb created in Access 2003), the access keys assigned to the two buttons on the form are ignored. I reduced the form to two buttons (&Save and &Close), one tab control with one tab page, and one label control on the tab control. I then added a second tab control in Access 2010. If I delete the label from the original tab control (created in Access 2003) and insert it onto the new one (created in 2010), the access keys on the buttons work fine. If I move the label back to the older tab control, they do not work. I get the same results whether the Ribbon is displayed or hidden.
Any ideas why that would happen? Unfortunately, this is part of a massive commercial application with over 400 forms, many of which use tab controls, and virtually all of which use buttons with access keys. So I can't easily replace all of the tab controls with new ones in Access 2010.
Thanks for any suggestions.
Barney Stone Stone Edge Technologies, Inc.
Answers
-
Friday, December 10, 2010 5:45 PMModerator
Hi Barney,
Unfortunately, I was unable to find a workaround. As mentioned before, I did report the bug to our development team so they are aware of the problem. Unfortunately, I can’t guarantee if or when it will be fixed since that is out of my control, but they will now be aware of it.
Best Regards,
Nathan Ost
Microsoft Online Community Support
Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.- Marked As Answer by Nathan O. - Microsoft SupportMicrosoft Employee, Moderator Friday, December 10, 2010 5:47 PM
All Replies
-
Monday, November 29, 2010 9:51 PM
Barney,
The only suggestion I have for you is this: fixup ONE form to work in Access 2010, and then export both the 2010 form (from wwithin 2010) and the same form (in 2003/2007 working format) and Export them both to text and compare the text files to look for differences between the two - perhaps there is/was a subtle "unadvertised " change afoot that we're not aware of as yet? if so, this may reveal the issue...?
Then we may be able to write a conversion function to make the same forms interoperate properly...? (not that this should be happening in the first place of course...)
Mark Burns, MCAD, MCP
Sr. Microsoft Access Analyst/Developer
Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN) -
Tuesday, November 30, 2010 3:23 PM
Mark -
I already tried exporting the form to text. At that point the form had two tab controls, one created in 2003 and one in 2010. I could not see any meaningful differences between them (other than things like size, position and names). Is there something I should look for outside of the Begin Tab / End sections of the text?
Thanks for your help,
Barney Stone Stone Edge Technologies, Inc. -
Tuesday, November 30, 2010 6:24 PM
Barney,
If you create a clean Db in access 2010 and import all the forms and database items form the 2003 version, what do you get then?
do the access keys work? ....or not? (then the next test is to try that same 2010-imported DB back in 2003...)
Mark Burns, MCAD, MCP
Sr. Microsoft Access Analyst/Developer
Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN) -
Tuesday, November 30, 2010 7:31 PM
I did some additional testing, and I think the problem is actually very simple: if the focus is on a control on a tab control, the access keys do not work. Here's how to duplicate it:
1. Create a blank form in Access 2010. (I have only done this with .mdb's, not tried with .accdb's.)
2. Add a button to the form. Make the caption &Close. Add a Click Event to display a message box when the button is clicked.
3. Add a text box to the form.
4. Add a tab control to the form. Add a text box to the tab control.
5. In Form View, click in the first text box (the one that is NOT on the tab control). Click Alt/c. You should see the message box from the Click Event.
6. Click in the second text box (the one that IS on the tab control). Click Alt/c. The Ribbon will react instead of the command button.
As far as I can tell this is consistent with other forms. They all work properly in earlier versions of Access. My earlier statement that a tab control added in Access 2010 worked properly was wrong. It just appeared to work because when I opened the form, the focus was on the now empty original tab. If I actually clicked in a field in the second tab, it had the same problem as the first tab. (An empty tab control with the focus will not cause the problem.)
Does that make sense?
Thanks again for your help.
Barney Stone Stone Edge Technologies, Inc. -
Friday, December 03, 2010 3:37 PMModerator
Hi Barney,
Thank you for posting the steps to reproduce the problem. I was able to reproduce it in Access 2010 but not in earlier versions. I'm going to file a report to make our development team aware of the problem. I'm looking into possible workarounds. I will post again once I've looked further into workarounds. Talk to you soon.
Best Regards,
Nathan Ost
Microsoft Online Community Support
Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. -
Friday, December 03, 2010 3:38 PMGreat! Thank you.
Barney Stone Stone Edge Technologies, Inc. -
Friday, December 10, 2010 1:58 PM
Hi Berney.
I have had the same problem and I just have create the following workaround:
- Create an unbound textbox on the form, but not on the tabcontrol, make the backcolour the same as your form colour, so you will not see this.
- Add the following code for your form:
Public Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = 18 Then 'The Alt Key
Me.txtFocusControl.SetFocus 'txtFocusControl is the name of the control
End If
End Sub - For each subform on the tabcontrol:
Public Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = 18 Then 'The Alt Key
MeParent!txtFocusControl.SetFocus 'txtFocusControl is the name of the control
End If
End Sub
Good luck !
Best Regards,
Bart Buné
-
Friday, December 10, 2010 3:16 PM
Bart -
Thanks for the suggestion. I tried that, but it did not work well. I had to type the access key twice - once to move the focus, and a second time to hit the command button. But it did lead me to a solution. In the KeyDown event, I simply test KeyCode and Shift (which should be 4 for the Alt key), then call the appropriate button's Click event. Finally, I set KeyCode to zero so it does not pass thru to the ribbon, which some keystrokes (e.g. Alt-c) tend to do. So far, that seems to be a workable solution.
In the meantime, Microsoft is aware of the bug and hopefully will fix it in a future service pack.
Thanks again,
Barney Stone Stone Edge Technologies, Inc. -
Friday, December 10, 2010 5:45 PMModerator
Hi Barney,
Unfortunately, I was unable to find a workaround. As mentioned before, I did report the bug to our development team so they are aware of the problem. Unfortunately, I can’t guarantee if or when it will be fixed since that is out of my control, but they will now be aware of it.
Best Regards,
Nathan Ost
Microsoft Online Community Support
Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.- Marked As Answer by Nathan O. - Microsoft SupportMicrosoft Employee, Moderator Friday, December 10, 2010 5:47 PM
-
Wednesday, June 08, 2011 9:49 PM
Has there been any progress with this problem? I'm also working on an Access 2010 version of our commercial application which has almost 200 forms, many with tab controls, and generous use of access keys. I've noticed that once any control on the tab control has the focus, access keys for any controls fail including those on the tab control. If any other control on the form not on the tab control has the focus, all access keys work including for controls on the tab control.
I can't imagine delivering an Access 2010 version of our application where familiar keystrokes used for years by hundreds of users no longer work. I'd appreciate any ideas or workarounds.
Rick Collard -
Wednesday, November 30, 2011 2:16 AM
Attention Nathan O and the Access/Office Product Team.
I can confirm this *exact* same issue in every context mentioned above. In A2003 and prior, Access 'hot keys' (ALT+<SomeUnderlinedKey) work 100% of the time, all the time, everywhere, anywhere, in all cases. Period.
I use transparent tab controls mainly to house a group of controls that need to be disabled/enabled quickly. I've used this technique for years since the tab control became available, and it works very well. With an A2003 mdb running A2010, any time a tab control has the 'focus' (ie, some control on a tab page has the focus), Hot Keys simply do not work.
This is entirely unacceptable. This problem was reported almost 1 year ago (Dec 2010). Clearly, this issue has not been addressed in Office 2010 Service Pack 1.
This is not a serious problem. It is a major serious problem and needs to be elevated to a 'must fix asap' status. And here is one good reason why:
Our company has a substantial investment in the Dragon Naturally Speaking (DNS) application, with the intent on reducing early onset of carpal tunnel syndrome. Almost all of my 25 Access apps in use by approx 200 users daily (in our group alone) are now 100% keyboard driven. The DNS macros scripts are heavily dependent on Access hot keys. Our users have written may DNS scripts to highly automate voice navigation within these apps.
OOPS: Broken!
The only good news is ... currently, only about 10-15 users are currently running in A2010 in our group, as I continue to test apps in A2010. However, our IT Dept has mandated that company wide (a HUGE enterprise), that by 1-1-2012, Access 2010 will be 'activated' on all users systems that require Access. Currently, everyone company wide has Office 2010. However, in our group A2003 is still in use except for the few users aforementioned. That luxury ends on 1-1-2012 !
Yes, the workaround (or similar) suggested by Bart Bune above can be made to work (I've created/tested a similar fix), but ... a workaround is simply not acceptable, as it requires a massive amount of ... what should be ... unnecessary coding!
PLEASE ... address this issue now! A fix needs to be in the form of a Service Pak as opposed to a 'hot fix', as I am not aware that our IT dept deploys hot fixes.
Joe Anderson
https://mvp.support.microsoft.com/profile/Joe.Anderson
http://www.experts-exchange.com/M_3699761.html
http://www.linkedin.com/profile/view?id=3225264&trk=tab_pro
Joe K Anderson, Microsoft Access MVP -
Tuesday, December 27, 2011 7:14 PM
Hi Nathan,
Would you kindly provide an update to the community on the status of this issue?
I find it unbelievable that a major flaw like this can go unaddressed for so long. Can't Microsoft with all of its resources address high level problems like this? How did this even make it through beta testing? Imagine if shorcut keys didn't work in .NET!
Can Microsoft at least build a hotfix to address this until it's rolled into a service pack?
Thanks,
Don Small, J&H Inc.
- Edited by Don Small Tuesday, December 27, 2011 7:15 PM
-
Monday, January 02, 2012 9:40 PM
I am wondering if we can get status on fixing this as well. We are a consulting firm and all of a sudden we're getting calls to fix this as people are upgrading their Office versions. Can we get this fixed and when???
Joy Eakins
Joy -
Tuesday, January 03, 2012 11:15 AM
I am wondering if we can get status on fixing this as well. We are a consulting firm and all of a sudden we're getting calls to fix this as people are upgrading their Office versions. Can we get this fixed and when???
Joy Eakins
JoyWe quote all!!
This change is necessary for the conversion of our procedures in Access 2010. We can not convert until it is correct.
Please Microsoft, correct!!
Erifa
-
Tuesday, February 28, 2012 5:17 PMAny word on a fix for this issue? It's been more than a year!
-
Sunday, April 01, 2012 11:37 PM
I have the same problem. I'd say Microsoft are too busy fixing all the other problems in the Office suite.
-
Sunday, April 01, 2012 11:57 PM
Folks ... I was told at the MVP Summit and the end of February that ... the probability of this being fixed was ... zero. Sad, but true. The only way this would get escalated would be if a LARGE company put the pressure on Microsoft to do so.
joe
Joe K Anderson, Microsoft Access MVP
-
Monday, April 02, 2012 12:29 AM
Thanks for the feedback Joe. Looks like it's time to instigate Plan B ...
-
Monday, April 02, 2012 12:44 AM
Plan B is to use the KeyDown event, trap what would be ... your shortcut (hot) keys - that are on buttons on tab controls ... then explicitly call the code behind the related button.
Joe K Anderson, Microsoft Access MVP
-
Tuesday, April 03, 2012 7:05 PM
Folks ... I was told at the MVP Summit and the end of February that ... the probability of this being fixed was ... zero. Sad, but true. The only way this would get escalated would be if a LARGE company put the pressure on Microsoft to do so.
joe
Joe K Anderson, Microsoft Access MVP
Last year I opened a support ticket for this problem and learned the bug had already been reported. After this bit of discouraging news I emailed the Access Senior Support Engineer who handled that ticket and asked if he had any news. He said he does not know if the bug is on the list to be fixed but he "just checked and the bug has not been closed so there may be hope."
Here's another annoyance with the Access 2010 tab control. If you set the control's Tab Fixed Width property to a value other than zero and the page captions include an access key you will get strange caption alignment within the tab. I can't seem to duplicate it now but I thought this behavior was affected by the database's Use Windows-themed Controls on Forms setting.
Another plan B option is to use Access 2007. But I'm not sure if ACE 12.0 has the same performance problem as Jet 4.0 on Windows 7 identified in this thread: Very slow Access 2002 query with Windows 7.
Rick Collard
-
Tuesday, April 03, 2012 8:08 PMI just discovered a simple kludge for a temporary solution. It appears that hotkeys still work in another form section. For example, if your tab control is in the detail section and the tab control has the focus all hotkeys fail anywhere in the detail section but they still work on controls in the header section. Add an innocuous control to the header such as a transparent button with a hotkey and you can use the hotkey just to give the header focus then any hotkey in the detail section appears to work. Yes, it's two keystrokes instead of one but it may be the best we can do right now. With this info maybe a more elegant solution can be found.
Rick Collard
-
Tuesday, May 08, 2012 9:12 PM
I just want to add my voice to the list of desperate people who need this to be fixed. My agency just upgraded from Access 2003 to Access 2010. I have a couple applications which are used by a blind person. The keyboard absolutely HAS to work for her. I was shocked when she called me into her office to show that vital keyboard shortcuts she has been using for years are no longer firing.
Then I found this page. I can't imagine why this wouldn't be top priority. It is a serious, huge bug...
-
Tuesday, May 08, 2012 9:25 PM
I couldn't agree more. I have forwarded your post to the Access Product Team. There should clearly be a Hot Fix for this.
Joe Anderson
Microsoft Access MVP
Joe K Anderson, Microsoft Access MVP
-
3 hours 43 minutes agoJoe: I didn't see your reply until now. Thank you *very* much for your efforts.