Can't focus sub form in tab control on first binding (1 Viewer)

[GK in the UK]

Per the title. In my TabCtlDetail_Change sub, I try to set focus to the sub form, then the sub form control. It doesn't work. Despite, Access reporting that that is where focus is.

TabCtlDetail_Change calls a sub to bind the page, then attempts to set focus as the last two lines.

I put a command button on the form to test with the same two SetFocus lines. Clicking it immediately after changing the tab sets the focus correctly. So the code is ok.

If I click to a different tab, then click back, focus is in the field. But never on first binding. In fact, I don't know where focus is.

Access reports:
Screen.ActiveControl.Name reports txtPickQty
Me.ActiveControl.Name reports OrderLines
But it isn't. So where is the focus ?

There's an issue which I think is related. I want focus to go to the sub form, because I want to test for KeyUp and KeyDown. On first click of the tab page, KeyDown fires, but KeyUp never does. Until I focus the field. How can the sub form, which must be active if it's responding to KeyDown, not respond to KeyUp ?

 

[theDBguy]

Hi. Are you able to post a sample db?

 

[GK in the UK]

Unfortunately I can't post it. I discovered that just minimising Access and restoring it enabled the focus and the key events. Then it crashed and wouldn't open again so I've had to revert to a recent backup. I'm going to have another look in a couple of days.

 

[theDBguy]

Unfortunately I can't post it. I discovered that just minimising Access and restoring it enabled the focus and the key events. Then it crashed and wouldn't open again so I've had to revert to a recent backup. I'm going to have another look in a couple of days.

Good luck!

 

[Pat Hartman]

In what form and what event is the code that doesn't seem to work?
Corruption is always possible also. Tell us what happens when you test with the backup.

 

[GK in the UK]

OK I've recovered and got back to where I was. Fixed a name ambiguity which wouldn't have helped. Done some more testing, my SetFocus commands are ok. I had a feeling this was going to be one of those "how did I miss that ..." and I think it is.

When I bind the tab for the first time, using SourceObject, Access is, I think, passing control up to the ribbon, or the menu commands. I noticed that Form Tools > Datasheet is highlighted when I click the tab. Just clicking anything passes control back to the field, including pressing the Windows Menu button. Then I get focus and both KeyEvents work without even touching Access.

So focus I think is in the right place but control has gone elsewhere. Still not sure why KeyDown fires but not KeyUp.

So - embarrassed to say how much time I've spent on this - I need to disable the ribbon, I guess. Why is this happening ? How do I stop it ?

I did build a menu form but I never bothered to disable the Access menus, this is Access 2016.

 

[GK in the UK]

Disabled the toolbar with DoCmd.ShowToolbar "Ribbon", acToolbarNo. I'm getting the same issue. Focus apparently is in the right field on the right sub-form but it's not ready to receive input. Sub-form KeyDown fires, KeyUp doesn't. Any ideas why this is happening ?

 

[Pat Hartman]

What is the purpose of using the "key" properties? EXACTLY what are you trying to do or to prevent? I use lots of tabbed forms and don't have any problems with them.

 

[GK in the UK]

Well, it's fancy functionality that has turned out to be a lot more complex that I expected.

To reduce the number of buttons on my form, two of them are dual-function. A main function, and a related subsidiary function when Control is pressed.
The functionality has worked perfectly and still does, but I decided it would be good to change the button caption when Control is pressed. To do that I have to be receptive to KeyDown and KeyUp on the main form AND the sub forms. But what is happening, is the sub form isn't 'active' on first binding.

Basic form layout:
Main form with Tab Control: TabCtlDetail
TabCtlDetail has 5 pages
Each tab page has a SubForm/SubReport
Code binds the SubForm/SubReport to a sub form on first click

The main form has KeyUp and KeyDown event subs (private)
The KeyUp and KeyDown subs each call a Public sub, also in the main form

The public subs are called KeyDown_Handler and KeyUp_Handler and have code to change a button caption on the main form.

Each sub form also has KeyUp and KeyDown event subs (private)
Each sub calls the public sub in the main form, it simply passes the parameters up.

All this works when the focus is where it should be.

Debug.print at the end of the tab control change sub (main form):

06/07/2021 21:46:14 TabCtlDetail_Change - Screen.ActiveControl.Name = txtPickQty < correct
06/07/2021 21:46:14 TabCtlDetail_Change - Me.ActiveControl.Name = OrderLines < correct
06/07/2021 21:46:14 Me.OrderLines!txtPickQty.Enabled = True < correct, field can take focus
06/07/2021 21:46:14 Me.OrderLines!txtPickQty.Locked = True < correct, field can take input

So, no other code runs at this point, this is the result after first click of the tab page with a mouse. The sub form is bound in code called by TabCtlDetail_Change.
I can see that the field txtPickQty, which is on a datasheet form, is the one that is highlighted but focus appears to be somewhere else. The field isn't ready to take input.

The KeyDown event of the sub form in OrderLines fires, but KeyUp does not. So, I press control, and the KeyDown event fires, the caption changes, but when I release Control, it doesn't revert. What is really weird is that the KeyDown event that is changing the caption, is the one in the sub form. Yet, KeyUp in the sub form does not fire.

I see this behaviour ONLY on first click of the tab page when the sub form is first bound.
If I click to another tab, and click back, the field is focussed. Both KeyDown and KeyUp events of the sub form fire and the button caption changes.
Same behaviour with the other tabs. On first binding, KeyUp does not fire, and the field, although highlighted, does not have the flashing cursor.

All I have to do to focus the field is to click anywhere on the main form, or the field, or another form in Access and come back, or minimise Access and maximise.
Focus will appear if I just click the Windows menu key, without even touching Access.
It seems like focus is going to the field, so the datasheet field is highlighted, then moving somewhere else, like another form.

 

[GK in the UK]

OK I've been working on it and it's not the Locked status of the field. I just set it explicitly unlocked to check. Same behaviour.

06/07/2021 21:59:10 TabCtlDetail_Change - Screen.ActiveControl.Name = txtPickQty
06/07/2021 21:59:10 TabCtlDetail_Change - Me.ActiveControl.Name = OrderLines
06/07/2021 21:59:10 Me.OrderLines!txtPickQty.Enabled = True
06/07/2021 21:59:10 Me.OrderLines!txtPickQty.Locked = False

 

[Pat Hartman]

Personally, I would never overload a button like this. My objective is to have the app's operations be obvious and not require training. If a button does one thing in one case and something different in another case, that requires training.

It is hard to follow the logic without seeing the code and the forms so I don't know what to tell you. Can you change the caption in the click event of the button?

 

[GK in the UK]

The actual button functionality is ok without the caption change, so I may just dump the stuff to recaption it. I cannot figure out how the sub form can respond to one event, but not another. It is clearly 'receptive' to repeated KeyDown events but ignores KeyUp events even though it's clearly loaded. But why on earth does this happen only on first binding ? Very odd. But thank you for considering this.

 

[Pat Hartman]

so I may just dump the stuff to recaption it.

But that is the only thing that makes reusing the button rational. At least with a caption change, the user has a clue as to what the button will do NOW. He may just have no clue how to revert back to its original use.