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.
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.
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.
Of course, as we know, there is no MouseDown event in the Web 2 Lisbox.
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 )
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.
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.