how to identify control in focus

[hicksi]

I have a UserForm that is dynamically constructed (depending on a not-predefined number of days), and while each dynamic textbox on that form has TabStop=False, there are a significant number of CommandButtons and frames that DO need tabstop enabled. I know that user-facing-controls (buttons, textbox, checkbox, etc) indicate when they are the in-focus control, but in the situation I am in at present, I need 15 clicks of the tab key to fully circumnavigate the controls that are on the form.

Nothing wrong with that, except there are only 4 controls that indicate their Focus state.

MY problem is that I need to identify the focused control (for debugging purposes) so that when the form is in the data-entry phase, they can all be disabled.

This is to increase user-speed. Ie, when set to the data-entry phase, the user needs to have 3 tab-enabled fields, an OK and a Cancel, so data is entered using ONLY keyboard - field1<tab>field2<tab>field3<tab><enter>, where the mini-form (a frame) stores the three values and jumps to the next day. If a check-error occurs, then the mini-form beeps and doesn't save. User decides which of the three fields is invalid and wants to <tab> to that.

YES, they're old-school, but when there's a need to key in lots of data, a mouse isn't user-friendly.

SO, right now, the 4th <tab> sets the Cancel button in focus, and 5th, 6th, 7th... I want to know what control is in focus so I can disable it during this process.

Any thoughts?

 

[Logit]

See if this works :

Sub IdentifyFocusedControl()
    Dim ctrl As Object
    For Each ctrl In UserForm1.Controls
        If ctrl.Enabled And ctrl.Visible And ctrl.SetFocus Then
            MsgBox "The focused control is: " & ctrl.Name
            Exit For
        End If
    Next ctrl
End Sub

 

[Rick Rothstein]

I think you can get the name of the control with focus on your UserForm while your code is executing using this...

ActiveControl.Name

 

[hicksi]

I think you can get the name of the control with focus on your UserForm while your code is executing using this...

ActiveControl.Name

I like how you think (that's a Muhammed Ali quote, BTW, slightly amended for the woke-generation)
But how do I get the system to report it without getting into multiple threads and the Schrödinger's cat theory?
My thought right now is to <tab> and then jump to the Immediate window to enter 'ActiveControl.Name'

 

[Jaafar Tribak]

Bear in mind that ActiveControl won't give you the correct focused control located inside containers such frames, Multipages etc.

 

[hicksi]

I think you can get the name of the control with focus on your UserForm while your code is executing using this...

ActiveControl.Name

Sadly that "sort-of" worked. I don't know where to place that in code that would allow me to get the information without taking control away.
WON'T work by entering a request in the Immediate window, as the program is running.
Didn't work as well as I expected by placing it as a Watch over ALL controls in the Form with Break at Change (which I expected to work).
It's definitely a valid command, as it works and shows changes when I stepped through the code.

In the end I tried an ENTRY and EXIT for frames, changing the backcolor to Green/ reverting to Azure (yeah, that code will be removed).
It appears to be tabbing through the various frames. So now my "Enable" process when starting the job has to set TabStop to False for those frames.
FYI, making then Disabled fails a different requirement, as you ALSO need the data-entry frame to collapse if the user clicks in those frames.

Who said Users weren't complex beings?

 

[hicksi]

Bear in mind that ActiveControl won't give you the correct focused control located inside containers such frames, Multipages etc.

Makes sense. As I have frames within frames within frames...

 

[hicksi]

ANSWER (I suppose) is to use some method to identify when a FRAME or a MULTITAB are in focus. I user Frame_enter to set a background color and Frame_Exit to set it to something else.
It's not entirely accurate, but it DID give me enough information to allow me to remove tabstops from them prior to running the data-entry frame.
DON'T FORGET to run your "disable" process in reverse before closing the data-entry frame.