WebListbox right click to retrieve row index? Using jquery?

Since I’m not patient enough to wait until there is a fix for the broken contextual menu in 2022r1 I have decided to use GraffitiMenu. It is actually a much better looking contextual menu anyway but it does not have a capability to extract the row that you are right clicking. My assumption is that since the current WebListbox is based on a standard table that allows you to use CSS styling and use some javascript I Googled Javascript to capture .table row from right click and there were a couple of jquery items that popped up. I’m not sure how to implement them or even if they would work in a Xojo WebListbox so I’m posting here to see what suggestions the good folks here in the forum might have. Here are the two things I found:

$("#tbl1 tbody tr").bind("contextmenu",function(e) {
$(document).ready(function() {
    $("#tbl1 tbody tr").mousedown(function(event) {
        if (event.which === 3) {

I’m guessing that I would need to do something to identify the WebListbox control ID and pass the event to a variable instead of raising an alert? I just don’t have any experience working with javascript or jquery and only really dip into using javascript when someone posts something here that is useful that I can plug into a Xojo project.

While theoretically possible as the WebListBox rows do have an index signifier (or based on their position in the TBODY), the problem becomes passing it back to Xojo. As I said earlier, a click to change the selected row(s), followed by the right-click is the best path.

But then I would have to suppress the contextual menu from working unless a row is selected, but when enabled a user could still right click on another row expecting the result to come from that row instead of the one selected. It may seem like the best way but users will not behave the way you think they should.

Ideally, you can do that with the SDK (documentation is in the Extras folder).

But if you want to do it “quick and dirty”, you can simply pass the value through hashtag, and get it with session.hashtagchanged.

Sub Pressed() Handles Pressed
  var js as string
  js = js + "location.hash = 'hello, world';"
End Sub

and in the event:

Sub HashTagChanged(Name as String, Data as String) Handles HashTagChanged
  MessageBox name
  HashTag = ""
End Sub

Thanks for the comment Michael but I still don’t have a clue how to implement the jquery code above. I do not know JavaScript. I’m a part time programmer and my time to learn another language is limited and my patience with broken features has worn more than thin.

This is my biggest frustration with Web 2.0. So many features that are missing that should be in controls or are but don’t work, and I get directed to invent them myself using JavaScript which I didn’t sign up to learn because Xojo always provided these features in Web 1.0. Meanwhile I go out and license a set of controls to fix the issues that are broken in Xojo and they don’t work as I need them to either.

WebListbox Contextual menus don’t work. They are broken.
GriffitiGrid does everything I need except auto adjust height for variable columns of long text like WebListbox so it fails my requirements.
GrafittiMenu works with WebListbox except there is no way to capture the row that is right clicked on.

Sigh… If anyone can actually help me with this issue feel free to PM me with a price so I can freaking move on with my project. Otherwise I will have to abandon my project until Xojo fixes the broken contextual menu. Hopefully in 2022r2 but who knows when that will be.

1 Like

Sorry for trying to help. Good luck with your impatience :confused:


Hi Michel,

You did help. It just wasn’t the help I was looking for on how to make the jQuery snippet work in Xojo. I am not impatient with you, I was just venting. After two years of attempting to effectively use Web 2 without running into failures that never occurred in Web 1.0 I think I’ve earned a little bit of impatience.

Since Web 1.0 is no longer supported I am attempting to migrate multiple applications that were created using Web 1.0 to Web 2.0. They are perfectly functional as they are, but at some point they may not be. Yet, even after two years I continue to find roadblocks that prevent the completion of these migrations due to broken and missing functionality. Or worse, what I think are bugs due to broken or missing functionality getting classified as feature requests and not getting fixed. I’ve been a Xojo/REALbasic user for over 20 years and a very satisfied customer until recently.

Sorry for the additional venting. Just know you are not the target of my frustration.

1 Like

I use the MouseDown event in Web 1 to do this. Since that fires before the CellClick event I simply capture the X, Y, and REALbasic.MouseEvent object into a custom property and then access it in the CellClick event. Works great, no javascript required.

Of course, as we know, there is no MouseDown event in the Web 2 Lisbox. :roll_eyes:

in web 1.0 i use this

i create 2 property on webpage o 2 weblabel control and in weblistbox click event code i set these property (or the text value of weblabel control) with row and column value and i use these valute in other weblistbox’s events (like doubleclick or other )

1 Like

Unfortunately there is no right click event and definitely no right click event that selects the row to reveal the row ID. Right click in Web 1.0 selected the row which in turn made the row ID available in the selection changed event. Web 2.0 you get nada.

Sorry I’m coming to the party so late, but I wanted to talk about the construction of the WebListBox that may interfere with your plan…

So… because the WebListBox is data driven, and the user can apply a sort by clicking on a header (not to mention that the underlying control also supports row dragging) it was decided that to keep everything straight that the rows needed to have their own unique identifiers and that those are the row identifiers that needed to be exchanged with the server to keep track of selected rows (and other things that may rely on consistent indexes).

Now, since the control is lazy-loading, and it only keeps a small portion of rows rendered on the browser at any given time, the “rows” in that table are not all there all the time. If you scroll down to item 150, rows 1-100 may be removed in the browser to keep things fast and current (underlying control, not a Xojo design). This is another reason why those unique ids became so important. You cant rely on the row “numbers” because they may simply not be there.

Sending the selected “row” of that html table back to the server doesn’t necessarily represent the row that the user visually clicked on.

Perhaps if it is possible to return the cell value of the right clicked row could be helpful enough? The user can then infer the row index from there if it is not possible to directly get reliable row index from right click due to lazy-loading? At least we have something to work with.

What happens if two rows have the same data in them?

Perhaps at least one of the colum can be RowID’s / Unique Index if the listbox is tied to a recordset.
The point is that there is a possible way, which can be manipulated, to identify the row index. If there are probable conflicting row id, it is up to the developer to prepare for this condition.
With the above, at least there are ways to obtain row index, with some restriction of course.


To be clear, I don’t really care what the actual WebListbox row ID is. I only care that I can select a row with a right click and then access the data within that row by WebListbox.RowSelected and specifically WebListbbox.RowTagAt(WebListbox.RowSelected).

At present a right click does nothing including Contextual Menus which are broken/don’t work. (68399 - “WebListbox Contextual Menu does not work”, which has supposedly been “fixed and is waiting verification from our testing staff”, but what that means is anyone’s guess until it is available in a release for real world use/testing.)

In Web 1.0 a mouse down regardless of whether it was left or right selected the row so that the data within was accessible via a selection changed event. This is the part that is missing from Web 2.0. It matters little to me how fast the data displays if I can’t access it in some way because it is not identifiable from some type of selection event. If I store an array index or a database primary key in the row tag it is accessible, but only if I can determine which Rowtag to look at. The combination of no right click row selection combined with broken contextual menus is pretty much a showstopper for me to convert practically every Web 1.0 application I have ever created to Web 2.0. My users expect contextual menus because it eliminates extra steps to perform their work. The other thing they expect is a functioning double click, (i.e. now double pressed), which also isn’t working correctly, but I digress.

This is how the contextual menu looks like in 2022r2, if that helps (sorry for the Gif quality):


I hope you all can test this soon.


Does the right click select the row?


1 Like

Thanks Ricardo. That will solve one of my biggest Web 2.0 problems. Now hopefully it wont be long before R2 is available. Maybe it will even include a fix for double pressed too, (fingers crossed).

1 Like

No worries @Tom_Dixon, do you have the case number around for the double click?

Thank you!