Tab sequence anomaly during edit. 1

[clyderose]

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:
[ul]
[li]cntnrFields = visible and NOT enabled.[/li]
[li]cntnrButtons = visible and enabled.[/li]
[li]btnSave = NOT visible.[/li]
[li]btnDump = NOT visible.[/li]
[/ul]
Edit button is clicked within cntnrButtons causes:
[ul]
[li]cntnrFields = visible and enabled.[/li]
[li]cntnrButtons = NOT visible and NOT enabled.[/li]
[li]btnSave = visible.[/li]
[li]btnDump = visible.[/li]
[li]First field in cntnrFields gets SetFocus.[/li]
[/ul]
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.

 

[Mike Lewis]

A quick question: If the Exit button is not visible, what makes you think focus is moving to it? In general, an invisible control can't receive focus. And, in any case, given that it is invisible, how can tell that it has focus.

You say that hitting Enter causes the click event of the Exit button to execute. That is most unlikely. What is more likely is that you have a button for which the Default property is set to .T. In that case, hitting Enter will cause the behaviour you are seeing. That is true regardless of where focus is at the point of hitting Enter.

And, by the way, it is highly unlikely that this has anything to do with a Windows 10 update.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clyderose]

I put a wait window "focus is in the exit button" in the gotfocus event for the Exit button within cntnrButtons to verify where the focus went after discovering the click event happened if you pressed enter when the cursor did not show again.
No changes have been done to this area of the form for a very long time.
Also when the cursor has disappeared and you click in what should have been the next TAB field it goes back to the correct sequence.

 

[Koen Piller]

Hi Clyde,

Your problem-explication is well detailed. It would even be better if you would upload here:
1) your form and the other form with the detailed list of comments
2) the structure of your table
Regards,
Koen

 

[clyderose]

The forms are part of a company wide management system. Each is called from other areas and also have the ability to open other forms etc.
They are not stand alone. Without the entire system you would not be able to experiment with it.

The key here is that this problem started out of the blue. This area hasn't been modified for over a year. The TAB sequence during edit worked properly.

Also:
Define Window causes the same issue.
In the GotFocus event of a field located in cntnrFields (as in my original post) define a window as a display to tell user what was acceptable for that field, activate the window. Edit the field or just TAB through. In the LostFocus event release the window and the TAB sequence will be messed up.
Of course, the containers etc would have to be set up as described in my original post.

So, two operations, "Do Form Whatever" and "Define Window Whatever" displaying on top of an open form when called from within GotFocus event, causes the calling form TAB sequence to Jump to an object in a container that is NOT visible and NOT enabled.

 

[Koen Piller]

Clyde,
no problem if forms are called from other sources also. It seems, reading your code, there are no other forms called.
Without the forms unable to give you any good advise at all. Up to you to release them or not, if not I call this case as closed.
Regards,
Koen

 

[Mike Lewis]

The key here is that this problem started out of the blue. This area hasn't been modified for over a year. The TAB sequence during edit worked properly.

You are right that this is the key. So, something must have changed. Is there any chance that you can figure out exactly what is different?

You mentioned the Windows 10 update. I can't imagine how that could possibly cause this problem to arise. But it is worth trying to eliminate it. Have you got a machine that has not received the update? Or one that is running an old version of Windows? If so, it would be worth seeing if the behaviour is any different?

For that matter, is the problem only present on one computer? Or on every computer on which your system is running?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Clyde,
Two shot in the dark: New AV ? Working under XP or Win7?
Koen

 

[clyderose]

I agree something changed.
So far it has been documented on two win 10 computers. One on the company network running the exe off the server and one completely stand alone in my office.
I have a win 7 I will try it on and get back to you. Good idea.

 

[clyderose]

It DOES NOT happen on a Win 7 I set up with the current version of the system.
It works as it should.
This is very troubling.
Any other ideas to try?
Oh and thanks for the feed back so far.

 

[clyderose]

I found the problem.
It is NOT Win 10 update. Thank goodness, that would have been a REAL problem.
Also, it happened on the Win 7 computer as well but I was in a hurry (actually working on another project while trying to identify this problem) and forgot that I had done a duct tape and baling wire fix to keep the system running for the client. Didn't have time to aggressively pursue a proper fix at the time it originally cropped up.

So yeah it appeared to work properly but the problem was "worked around".

Anyway, in the Form Activate event I had put:
thisform.cntnrButtons.btnExit.setfocus
Don't remember why but probably some user feedback complaining about where the focus defaulted when opening the form.

Apparently in the Activate Event for the form, which is triggered anytime the form becomes the _screen.activeform, it doesn't matter if the object is visible or enabled. Which certainly surprised the crap out of me.
So I added IF visible code and now it appears to be working fine.
Thanks so much for the input. It certainly helped finding the problem!

 

[Mike Lewis]

Good to hear you found the cause of the problem, Clyde. And thanks for letting us know. I still don't understand how an invisible control can get focus, but never mind.

By the way, if the reason the user made the request was that they wanted to execute the Exit button just by hitting Enter, an easier way would have been to set the button's Default property to .T.

Mike
P.S. I like the image of the system running with duct tape and baling wire.

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clyderose]

Hmmmm, had to do some research to figure out what the Default property did. Never used it.
A significant part of this particular LARGE VFP software package dates back to 1986. Many of the users (old farts like me) still use the Enter key to move from field to field. Teaching them to use the TAB key is an unwinnable battle. "Improving" some areas is NOT allowed.
So I have to be careful about what the ENTER key does in some modules.
Thank you for your input and thoughts. Particularly insisting a Win 10 update was NOT the problem. It forced me to realize it was probably something I did. (What? NOT infallible??)

BUT there had been no major changes to that form since 2017!! OH well, modifications made on the fly come back to bite you occasionally.

The way I found the problem was by digging out a copy of that form from 2017, making a PRG file of the code and then going through line by line comparing it to the current version code! My eyes are still crossed.

As you can imagine the compatibility issue is always a BIG worry when maintaining a VFP system with areas that were originally written for FPD26. Ahhh the good old days.

By the way, do you have any thoughts on a viable FoxPro replacement?
Have fun,
Clyde

 

[clyderose]

Also, just got feed back from another source.
If you do a .SetFocus in the Form Show event then the TAB sequence will NOT be affected by calling another form from within a GotFocus.
Thanks to all.