By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,346 Members | 2,318 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,346 IT Pros & Developers. It's quick & easy.

KeyDown, KeyUp won't fire from Access datasheet subform

P: 7
This is a follow-up to my previous Access issue of synchronizing the scrolling of a datasheet form with a datasheet subform, which works fine.

I am using Access 2016 under Windows 10.

Because the scrolling solution above is executed by the AfterUpdate() event, it occurred to me that a user may circumvent the solution by starting his/her journey through the subform, using multiple Tabs, Enters or R-Arrows to land on a starting control of interest. These controls are weeks in a year-long Labor Plan. The data entries are % commitments to individual projects (Person & Project identifies a record).

So I built a procedure on the KeyDown() event to test whether the user has used any of these navigation keys. If they have, I want to execute the .SetFocus routines that are in the original solution. However, I can't get the procedure to respond, using a KeyDown or KeyUp event.

I even placed a MsgBox ("got here") just below the first statement:

Private Sub Ctl2_3_19_KeyDown(KeyCode As Integer, Shift As Integer)

I checked all the Data and Other properties on the control-under-test, and they appear to be the usual system defaults.

So what is going on? All of my references indicate this should work.

I'll mention again that I am an Access/VBA neophyte - you won't offend me by stating the obvious.

Thanks in advance,

Mar 5 '19 #1
Share this Question
Share on Google+
2 Replies

Expert Mod 2.5K+
P: 3,284

If I remember correctly, you can't use events in datasheet the same way you can in a regular form. This is so because the "sub-form" is really the table itself. Yes, you establish controls inorder to determine which fields to display, but it does not function the same.

I think we kind of touched on this very early on in your quest for answers in this form of yours, but, if you had a true sub-form and true controls, you could "simulate" scrolling of the records from left to right.

For example, let's say you have 25 fields you need to display, but the form is only wide enough to show 10. This would take some calculating of how wide each control would be, but, you could hide any controls that "fall off" the left or right side of the Form and move the visible controls to the right or to the left, based upon the width of the most recent control made invisible.

In theory, this would work, still allow you to scroll up and down normally, AND it would get you away from the "simulated keystrokes" which can be unpredictable, and, as you are finding, a bit difficult to manage all the possible exigencies of normal DB navigation a user expects.

Hope this hepps!
Mar 5 '19 #2

P: 7
Dear Twinnyfo

I think I owe the community a follow-up. As mysteriously as my KeyDown event would NOT fire yesterday, today it does (without any changes).


I do realize that some functionality is lacking to Access forms in datasheet view. This event problem, however, did not make sense, because my AfterUpdate has been firing perfectly from day one.

What I surmise from this recent experience is that something on the network was disabling some portion of the work I had put into the new procedure. The network I rely on is corporate/worldwide and has over 100K customers - it has also been very volatile of late.


Mar 6 '19 #3

Post your reply

Sign in to post your reply or Sign up for a free account.