If I recall correctly, you might be able to identify the control that actually has the focus by trying to capture its name. Screen.ActiveControl.Name should be the thing that gained control. Further, if you were in doubt, Screen.ActiveControl.Parent.Name should be the form holding the control that has focus. So if you put a couple of string variables in that module and loaded them with those two names and then put in a breakpoint AFTER those names were loaded, you could do a Debug.Print on the variables to see the form name and control name having focus.
SetFocus doesn't always work as expected. Don't forget that your command button will attempt to undergo a "LostFocus" event if you try to set focus elsewhere. That is, if your button_Click event does the SetFocus, you will still have to undergo the LostFocus. Does the button have an active LostFocus event?
If it were left to me, I would maybe put a breakpoint on the line of code that does a SetFocus where you wanted it, then single-step to see what routines fire and in what order. I guarantee you have not less than five potential events pending if that is as you described it. The button's LostFocus, the parent form's Exit, the child form's Enter and Activate (or maybe it is Activate and Enter, I can never remember which one comes first), and the child form's control's GotFocus. If any one of those events does things to either form, that is where your focus went.
