Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author

  • p2806

    A little more information – I suspect this has to do with how things like tooltips are built. The method we use for doing so comes straight from your examples on pages such as

    E.g., the toolbar with buttons and tooltips seems to be built and re-built every time the component is rendered (snippet from an example on the page linked above):

        let renderToolbar = (toolBar) =>
            let toTheme =  (className) => {
                if (theme == "") return className;
                return className + " " + className + "-" + theme;
            // appends buttons to the status bar.
            let container = $("<div style='overflow: hidden; position: relative; height: 100%; width: 100%;'></div>");
            let buttonTemplate = "<div style='float: left; padding: 3px; margin: 2px;'><div style='margin: 4px; width: 16px; height: 16px;'></div></div>";
            let addButton = $(buttonTemplate);
            let editButton = $(buttonTemplate);
            let deleteButton = $(buttonTemplate);
            let cancelButton = $(buttonTemplate);
            let updateButton = $(buttonTemplate);
            addButton.jqxButton({cursor: "pointer", enableDefault: false,  height: 25, width: 25 });
            addButton.jqxTooltip({ position: 'bottom', content: "Add"});
            editButton.jqxButton({ cursor: "pointer", disabled: true, enableDefault: false,  height: 25, width: 25 });

    That said, the JqxMenu that was exhibiting the same problem is just a normal <JqxMenu> tag in our JSX, so the problem seems like it could be fairly fundamental? (and don’t forget the listBoxjqxWidget elements which I suppose come from things like JqxComboBox)

    • This reply was modified 2 years, 10 months ago by  p2806.


    I’ve already viewed your suggested approach, and shown you some code based on that, so it should be clear that I’ve tried to adapt your idea. You seem to assume that our data table would be built the same way as a simple demo snippet, which will never be the case.

    Because JQWidgets does not provide a way to obtain the list of selected indexes from a data table (and the row data does not provide a “uid” (nor any other attribute) that is a simple index as in your example), there is no choice — we MUST use two loops, because we have to compare the previously selected objects with the full list of row objects. These are all shortcomings in JQWidgets that we have had to work around with extra code that bloats our application.

    Where did you see in my code above that I was passing the row item to selectRow()? I am clearly sending the index. I would appreciate if you would pay more attention and make suggestions that are more accurate. The problem turns out to be that the index in the loop was a string and selectRow() only wants an integer, so I have it working for now (so thank you for the idea), but it’s not very pleasing that we have to go to such lengths to make JQWidgets do something this simple.


    Any comment on this or how I can debug it?


    FYI, blur does not fire, so onkeydown with check for keyCode === 9 is the only solution that currently works.


    Ours isn’t the newest React version. We have:
    “react”: “^15.5.4”
    I forget where to see the JQWidgets version number, but looking inside jqxcombobox.js shows version 5.6.0. Doesn’t JQWidgets use its own code to implement its widgets, such that a problem like this would be irrespective of React version?
    I used onkeydown handler to detect tab press to fix it, but blur as you suggest is probably a better solution, thanks.


    I tried your technique but found incredibly that selectRow() does not work unless its argument is hard-coded. This is quite odd, but no matter what I changed, it remained the case. The contents of my timeout function are as follows (it’s highly inconvenient that you do not provide a method on the data table to get a list of selected row indexes!) (selectedRows is obtained earlier using getSelection()):

    let allRows = this.refs.myTable.getRows();
    for (let i in selectedRows) {
      for (let j in allRows) {
        if (allRows[j].MY_ID === selectedRows[i].MY_ID) {
          console.log('Selecting row ' + j);

    You don’t need to spend much time looking at the rest of my code, because the console.log() does show the correct row index values, thus the code works as it should. The incredible thing is that the rows simply do not get selected, UNLESS I hard code them – for example instead of index “j” I hard code to index number 2:


    Again, the console.log() shows the correct, desired rows to be selected, and I would expect selectRow() to thus select my rows, but it simply does not. How can this happen?


    I see you suggest using a Timeout to restore the original selected state. Note that simple demo code has tables that do not select a row upon right click — only left click selects a row. This is what should be expected, and I hope JQWidgets can add this fix to your next version. If you have comments on where I could introduce that fix myself, that would be appreciated.


    Sorry that I do not have a simplified example available, but it may help you to know that I’m using the React version of the JQWidgets library. This bug happens on all of our combo boxes with drop-downs and freely editable text, so I feel somewhat confident that it’s not particular to our environment (except possibly the React version of your code)

    Regarding your comment that “it always selected the next element,” this is not the bug. Yes, it does select the next element when pressing tab, but the drop-down does not close.


    Your example only shows a button — no table is rendered.

    Regardless, it should go without saying that a *click* event de-selects the other rows. You seem to want to demonstrate your solution with a button, which is irrelevant. The problem is that the mouse click selects the row where the click happened and de-selects all the other rows. So please suggest a better solution. If the global “onClick” event is involved, great, I *want* to cancel the event.



    You seem to have missed this from my first post:

    Unselecting the row after the fact is not a good solution because there may have been other rows selected that will be lost. I do not want to lose the current selection status on the entire table.

    So your suggestion is not workable. Can you please explain why I cannot stop the event propagation and suggest a workaround?

    Thank you

Viewing 10 posts - 1 through 10 (of 10 total)