I have a Web app that, until recently, allowed the Tab key to work on any WebPage as soon as the page loaded. That is, with no field selected, I could just start hitting the Tab key and field selecting/focussing would start. Now I notice that on certain pages this is no longer is true. On those pages, I must first select a field with the mouse for the Tab key to start working.
What might have changed?
Did you add any controls to the page?
Have you checked the tab order for the page?
Hi, Greg. Well, it seems to happen to multiple pages, on which one two have and added control, at the most. And I checked Tab Order, making sure the field on each page I want the tab key to start with is enabled and has Tab Position 0.
On one page, I solved the problem by changing the order events that take place in the Session.Open handler. If I had the logging event (a database update) in the Session.Open event occur AFTER it calls the WebPage.Show event, it works for that one, initially called, WebPage, but not the others.
I also checked to see what would happen if I eliminated the database logging event in the Session.Open event altogether, and again that helped the initial called WebPage but not the others.
What I have resorted to is using Field.SetFocus on each problem WebPage in its WebPage.Shown handler. But if I should unFocus by clicking on open space, the Tab key is useless until I use the mouse to focus a field again. It appears that Tab and Shift-Tab at that point are working on browser elements other than what Xojo has drawn in it (browser tabs, bookmarks, etc.) whenever I unFocus with the mouse and start hitting Tab or Shift-Tab again.
What worries me is that perhaps there’s some corruption here. Not sure if that happens with Xojo the way it can happen with Filemaker. With Filemaker, I have tools to check for that. Is there something like with Xojo?
Would experienced Xojo developers here start to assume there really is some sort of corruption that creeped into my project here? If so, I could very carefully rebuild this project from the version that is working properly, slowly adding and changing things to match the current version, testing after each major change in code or control.
You could start with one page and see where it takes you.
Thanks for your typical patience and concern, Michel.
By adding and changing the older good project, piece by piece, I located the bug in my code. The Session.Open event calls a AddUserLog() method. That method grabs values found in various Properties that are set when a URL Parameter is received and parsed in Session.Open. If no URL Parameter is received (or only a partial unacceptable one is received), Session.Open opens WebPage1 and logs that event with AddUserLog(). If a fully acceptable URL Parameter is received, Session.Open opens WebPage2 and logs that event with AddUserLog().
The catch was that if a full acceptable URL Parameter is NOT received, some of those Properties that are set when parsing that URL Parameter are not set, or not set properly. As mentioned above, AddUserLog() uses all those Properties when creating the User Log for the database. So I created an alternative AddUserLogSimple(), specifically for Session.Open, that ignores those Properties that might not be set if the URL Parameter that is received is absent or not fully acceptable.