WebListBox : Navigation Using Keyboard No Longer Possible?

Hello everyone.

In Web 1.0 i think it is possible to navigate between rows
using keyboard only. This is crucial for data heavy application where the users usually navigate quickly using keyboard.

Is it no longer possible to do that in Web 2.0 WebListBox?

Is there any way to enable this?
We are migrating some of our application and noticed this behaviour.
It would be heavily detrimental to this application if users are not able to scroll using keyboards.

Thanks in advanced.

From what I read the basic datatables (the product that Xojo based the Web2 Listbox) has no keyboard navigation.

Searching their site I found that they have an extension to do keyboard navigation called keytable:

You can create a Feature Request, that way @Ricardo_Cruz can look at this option and see if he can add it to a future Xojo release.

If you need something now maybe GraffitiSuite has something. I read that a couple of users in the forum created their own Listbox replacements with the features they need, but their just for their own use.


Thanks @AlbertoD . Looks like it is possible to extend the current Xojo WebListBox / DataTables to accept keyboard input via some settings. @Ricardo_Cruz any possibilities / hacks to allow this? Or does it requires a different license to DataTables?

There is a Feature Request for this, please add your thumb up:
WebListbox to have an option on how arrow keys change the selection

I’ve been checking the “keytable” extension (thanks @AlbertoD!) and I’ll mention it in the opened case, but the way it works would be maybe too different from our DesktopListBox. I think we could just prepare something simpler to make it act like the DesktopListBox.


Once again, more “workarounds” for features we came to rely on in Web 1.0. :roll_eyes:

@Bart_Harrison, this feature has been implemented and will be shipped with 2022r3.


Sometimes we need the workaround until a feature request is added to Web2.
Ricardo is doing a great job fixing bugs and adding features.
If you want a workaround to be part of Web2 for the next release, make sure that it is reported in Xojo Issues.
If it is a bug and is important to you, you can vote for it for the August bug bash event (I think the limit is 10 nominations per person).


How about control groups and a property to set RowHeight in the weblistbox. We shouldn’t have to request important features we already HAD !

Sadly we do, the design is different. Even when Xojo said that some features will be added later, we don’t know what features they are thinking on bringing back.

Adding a feature request is the best way for us to track that something that we want/need could be worked on.

FEATURE REQUEST: Add Apple Silicon support to Web 1.0 and many of us will stick with that !!


What case number is that?
I can’t find it in https://www.xojo.com/issues

1 Like

Make the feature request on issues

1 Like

Too bad the ‘an update to the OS’ doesn’t apply here.

I don’t think Xojo will create Xojo2019r4 with support of Apple Silicon. Too many things need to change for that to work.

Could XojoWeb1 for Apple Silicon be created? Like a different product based in Xojo2019r3.2 but only for Web?

Be realistic. Why would Xojo create an Apple Silicon Web 1.00 ? Especially since with Rosetta 2, Web 1.00 runs perfectly under AS.


As we know, no form of emulation is as efficient as native. Besides I’m not talking about the IDE, I’m talking about the final compiled app. Since Xojo uses LLVM this shouldn’t be an overly ambitious task. Call it Web Classic or something and allow long-time users the choice.

Sure, it would be nice to have Web 1.00 native on Apple Silicon. But it is extremely unlikely.

Besides, Web 1.00 is much more often deployed under Linux than on local Mac.

Xojo decided to part from Web 1.00 and won’t go back. Your best hope is to adapt to Web 2.00, even if that means applying some level of JavaScript or CSS to get features like setting row height.

1 Like

I tried using Javascript to do this. It had the unintended side effect of applying white-space padding below the active rows when the user scrolled down (yes I did file this as a bug).

Some say websites don’t often use listboxes but I don’t develop websites.

Here’s an example of Web 1.0 embedded listboxes being painted-in dynamically. It works perfectly.

In Web 2.0 this was a horror show. I couldn’t even control the height of my rows and all the listboxes refreshed by themselves every time the container became visible. I couldn’t stop it.