I have this statement:
LBFolders.SetFocus
Tried in various places. LBFolder is a WebListBox. The listbox never gets the focus. Tried on Safari.
I’ve not seen any mention of this problem, either in Feedback or in this forum; however, such a basic call not working should have raised a lot of questions, I’d think.
Does it work for someone else?
By the way: any idea how to sort forum results by creation/modification date? The problem being, questions made years ago are no longer relevant, so when I (or anyone) search for something, the results are mixed and I quickly give up reading all the posts since they can be outdated.
About the Weblistbox, it does not really get the focus. You get the selection bar only by clicking on it. But yet, it is not a focus as you would get with a WebTextField, for instance.
Likewise, the Desktop Listbox does not really get the focus unless you make cells or columns editable.
[quote=466549:@Michel Bujardet]About the Weblistbox, it does not really get the focus. You get the selection bar only by clicking on it. But yet, it is not a focus as you would get with a WebTextField, for instance.
Likewise, the Desktop Listbox does not really get the focus unless you make cells or columns editable.[/quote]
I don’t want a focus to edit the control, so, in my opinion, both the TextField and the ListBox should behave the same (have a focus ring and handle keys such as the arrows). Having the focus doesn’t mean a text is being edited, just navigated.
Here’s my problem: I have a WebListBox and a button. The button shows a WebDialog. When the dialog is closed, the listbox loses its focus (probably because the button takes it, but it doesn’t matter). So the user has to click on the listbox to set the focus back to where it was, which is not good.
If the SetFocus method was only for a TextField, it wouldn’t be implemented in the WebControl, right? I think it’s broken.
[quote=466555:@Arnaud Nicolet]I don’t want a focus to edit the control, so, in my opinion, both the TextField and the ListBox should behave the same (have a focus ring and handle keys such as the arrows). Having the focus doesn’t mean a text is being edited, just navigated.
Here’s my problem: I have a WebListBox and a button. The button shows a WebDialog. When the dialog is closed, the listbox loses its focus (probably because the button takes it, but it doesn’t matter). So the user has to click on the listbox to set the focus back to where it was, which is not good.
If the SetFocus method was only for a TextField, it wouldn’t be implemented in the WebControl, right? I think it’s broken.
Thanks.[/quote]
I believe you are chasing a wild goose.
But you may want to prepare a small project that demonstrates what you think is broken, and join that to a feedback bug report.
As a user, wouldn’t you get tired of always clicking the listbox you were at when you get back to the main page after a dialog closes? And users may just get confused that they cannot continue the workflow (using the up/down keys to select another row, for instance).
Yes, if I’m not the only one to think it’s a bug
Thanks.
I worked more than a little on the WebListbox to extend it’s features.
Your comparison with a read only TextArea unfortunately does not stand. It so happens that the underlying html element, the Table, does not accept focus at all in it’s readonly state, and gets focus only when allowed to edit a cell. WebListBox does not offer the possibility to edit a cell.
Xojo went to great length to present the user with the closest appearance to the Desktop Listbox. To do that, it uses a Selected class which is applied to an entire row when the user clicks on it. That is in fact a pseudo selection, smoke and mirrors.
That said, I know from another thread you are more or less fluent in JavaScript. To put the WebListbox in the same state as when it is clicked, you need to set each cell in a row to the Selected class.
The Selected class is applied to a <tr> tag within the _userrows table to make the blue “selection” bar appear. That said, I quickly tried to deselect the WebListbox by applying focus to a WebTextField, and never does the WebListbox loses it’s selection on Mac, Chrome browser.
Perhaps what you see is specific to Windows.
At any rate you now know where to dig, using the browser developer tools.
I had the belief that SetFocus would allow the user to navigate the list with arrow keys, even though none of the cells are editable on Web. Would be nice to know if that’s officially supposed to work.
It is not possible to navigate the WebListBox with up and down keys, on Mac with Chrome and Safari, on PC with Chrome and Edge.
I don’t believe WebListBox was ever conceived to be operated with arrow keys. My quick tests show it actually does not work. You may be confusing with Desktop ListBox.
I believe you could implement navigation with up/down keys in the webPage onkeydown, using SetAttribute, as I showed you in the event thread. If I remember right Internet Explorer may not provide these keys, though. But it has been a couple years since I looked into it.
But you have to realize that in fact since WebListBox does truly get focus, you will be getting keys from the WebPage, and it could interfere when using the same keys in a WebTextArea, for instance. So you would have to suppress that feature when a WebTextArea or other control that uses up/down keys is focused. That should be possible using flags.
I’ll try that. For now, it looks over complicated. I mean, if Xojo can put focus on the listbox when the user clicks on it manually, then the SetFocus method should be able to do the same.
Thanks.
[quote=466564:@Michel Bujardet]That said, I quickly tried to deselect the WebListbox by applying focus to a WebTextField, and never does the WebListbox loses it’s selection on Mac, Chrome browser.
Perhaps what you see is specific to Windows.[/quote]
No, Safari on Mac. I haven’t mentioned the listbox looses its selection, but it looses the focus (the ability to get key presses).
Isnt this the result of a preference setting in macOS?
Make sure that System Preferences -> Keyboard -> Shortcuts -> Full Keyboard Access: … -> All controls is selected.
[quote=466573:@Michel Bujardet]It is not possible to navigate the WebListBox with up and down keys, on Mac with Chrome and Safari, on PC with Chrome and Edge.
I don’t believe WebListBox was ever conceived to be operated with arrow keys. My quick tests show it actually does not work. You may be confusing with Desktop ListBox.[/quote]
Actually, it works fine in Safari (on Mac, obviously).
[quote=466573:@Michel Bujardet]
I believe you could implement navigation with up/down keys in the webPage onkeydown, using SetAttribute, as I showed you in the event thread. If I remember right Internet Explorer may not provide these keys, though. But it has been a couple years since I looked into it.[/quote]
Well, I don’t expect Internet Explorer to be that useable at all, so no problem I prefer to allow as much as possible, according to each browser’s capabilities.
Actually, I’m facing with this kind of problem at the moment. On a given page, the KeyPressed event looks to execute only on the control that has the focus (like on a desktop app). If I want to handle shortcut keypresses, like the “+” key to mimic a button pushed, I have to handle it from any control that possibly have the focus (including other buttons, in my tests). I redirect all KeyPressed events in a method.
Thanks.
[quote=466578:@Paul Sondervan]Isnt this the result of a preference setting in macOS?
Make sure that System Preferences -> Keyboard -> Shortcuts -> Full Keyboard Access: … -> All controls is selected.[/quote]
I’m not sure this setting applies to web; perhaps it does.
However, the issue is that a WebListBox gets the focus with a click but not with SetFocus, regardless of this setting.
Thanks.
Arnaud, the issue, here, has drifted from the need to “set focus” to the WebListbox, to keyword control. Maybe I should not have gone into the JavaScript nitty gritty under the hood.
You can read the selected row with WebListBox.Selected(), and set it with something like