Web container Controls currently do not work in a commercial usable manner.
If you put a container control on a page, when you click on ANY control on that container. On the fist click, the focus will always go to the same control no matter which one the user actually chooses.
If you out two container controls on the page things get down right weird.
I have reported this as bug 67914. Does anyone have a work around?
This is what happens:
Hi, thanks for the Feedback case, screenshots and video.
I don’t have the computer around, but I guess the click event might be fighting with the tab. Hopefully a JS work around is possible, while a permanent fix arrives.
I believe it’s returning focus to the last control that had focus in the conainter. At least that’s the behaviour I’m seeing over here.
It is putting the focus on the first control that was created in the IDE.
It appears as if the first click is actually clicking on the container as a whole. And the focus is on the container. It then goes to the first control in the container by default.
This bug is insidious. Normally we can find work around. At his point all we can do is “not use containers” does anyone have a workaround that isn’t as brutal as that?
Here’s a very wrong way to do it, which I don’t recommend. Don’t use this in production.
In Session.Opening:
ExecuteJavascript( "XojoWeb.TabEngine = {};" )
This will replace Xojo Web’s TabEngine class with an empty object causing it to fall back to the default browser behavior, which will cause things to break like focus events (and make debugging JavaScript in the browser a real pain due to constant exceptions).
Dare I mark this as “Solution”?
I wouldn’t because Anthony mentioned side-effects.
However, Xojo staff member who might be reading this – that is the real long-term solution. The overbearing tab engine needs to be ripped out and thrown in a fire.
Agreed. Do not mark as a solution. If you want to test it for side effects and see if it meets your needs to use in production, that’s on you, but I know there are issues that make it fairly undesirable.
Also agreed: the TabEngine infuriates me.
That may have worked. But only in the same way fixing a fine watch with field artillery does. As you predicted. Many may side effects. So many I couldn’t even get to the page with the core issue. Anybody else have any ideas?
No, that’s why the WebTextField that gets the Focus is the second on the example. That WebTextField was the first put on the Container, then the third, and last the first.
If we set the tab order in the container, the first (top) WebTextField will get the focus when we first click on a WebTextField in that container.
If you download my mod from the case 67914 you can see that if instead of clicking a WebTextField you click the Button in the container, then the Button gets the Focus. That is what should happen when we click a WebTextField but in fact, we get two Focus events, one for the WebTextField that we clicked on, and another for the WebTextField that gets the Focus.
I hope you have an idea to fix this. Thank you Greg for looking into this.
Initially I had not set the tab order in the container. And the Odd behavior exhibited itself.
Then I did set the tab order and, unfortunately, I still get the odd behavior.
Here is the lowest common denominator/ most simple project we could come up.
Bug 67914 is preventing us from deploying an important update to a webapp. We are adding controls to a container dynamically and setting the tab order for each one. Users click into any of the textfields and it is impossible to click the correct textfield on the first try.
I want to thank @Ricardo_Cruz for working on this and I understand it is not a simple fix and will more than likely not make it into this release. If anyone can put their points toward this, it would be appreciated. If there is any reliable work around, let me know that too.