>>>Greetings,
>>>This edit routine worked properly until about 2 weeks ago when a user noticed and reported this change in behavior. The problem may have started before that, but because the user can just click on an individual field, edit and then save, the tab sequence change would not have been noticed. Description:
>>>A form with multiple containers, one with fields (cntnrFields) and one with buttons (cntnrButtons). Also two independent buttons (btnSave, btnDump).
>>>Over all tab sequence: 1 - cntnrFields, 2 - cntnrButtons, 3 - btnSave, 4 - btnDump.
>>>And of course separate tab sequence within cntnrFields and cntnrButtons.
>>>
>>>Initial settings for form viewing:
>>>cntnrFields = visible and NOT enabled.
>>>cntnrButtons = visible and enabled.
>>>btnSave = NOT visible.
>>>btnDump = NOT visible.
>>>
>>>Edit button is clicked within cntnrButtons causes:
>>>cntnrFields = visible and enabled.
>>>cntnrButtons = NOT visible and NOT enabled.
>>>btnSave = visible.
>>>btnDump = visible.
>>>First field in cntnrFields gets SetFocus.
>>>
>>>User edits and tabs thru fields until reaching the Comments field (txtComments). All works normal.
>>>In the GotFocus event a messagebox is displayed offering to select from a default list of comments. If NO is clicked then the user goes straight into the comments field and edits and tabs out to the next field. TAB sequence continues normally.
>>>BUT, if YES is clicked a new form is opened displaying a list of default comments, the user can check mark one or more comments, click EXIT, the comments are inserted via This.Value=. THe New comments are displayed AND the cursor disappears. Normal operation was to have the focus in the Comment field for any additional editing. Also Focus does NOT go to the next field in the tab sequence.
>>>After much experimenting I found that the focus has gone to the first TAB sequence (EXIT button) in cntnrButtons. Which is NOT visible and NOT enabled. If you hit ENTER at that point the click event of the EXIT button is activated and the form is closed.
>>>If you continue to TAB it goes to btnSave (skipping any other buttons in cntnrButtons) and btnDump AND then additional TABbing goes back to the first TAB field in cntnrFields.
>>>
>>>Anybody have any ideas? Like I said this form was operating properly for MANY years prior to this anomaly popping up. I assume it is due to a Microsoft Windows 10 update.
>>>Thanks in advance for any help or ideas.
>>
>>Do you have form-level activate or gotfocus events?
>>Another thing to check is if there is something with the Mouse configuration -- I believe there's an option for the Pointer to automatically move the mouse to the default button on a dialog box -- perhaps this could be causing the focus to jump to location where you're not expecting.
>>
>>It turns out there was a form level activate event pointing to the exit button. Which surprised the crap out of me as the container of the button was NOT visible and NOT enabled! It should only have SetFocus at initial instantiation of the form. Oh well. Regardless thanks for your response! Fixed it.
>
>It is best to never put any code in the Activate event. Until now I have never seen a case where this would be required or actually would make sense to put code there.
>
>The activate event triggers whenever a form becomes the _screen.activeform. When first instantiated this can set the focus to the button, field, whatever that works best for the user. The problem was that the Activate event circumvented the fact that the btnExit was in a container that was NOT visible and NOT enabled. Adding a qualifying IF to determine the visible and enable status solved the problem. Activate has its uses, BUT is has some odd behavior.

In this case I would have tried to put the Setfocus() call into the Show event. I have seen so many cases where code in activate has created problems, that I steer away from that event.