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.
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.
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.
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.
TL;DR
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.
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).
Ricardo, not yet. I recently filed 68511 - WebTextField.TextChanged does not fire when text is changed in code not UI, but I have not yet had a chance to create a test app for the double pressed issue to file a case with. Hopefully I can get to that today.
