[TP_DTNAParticipant]

In the source for your data adapter, check into these two callback functions: formatdata and loadServerData

the first one allows you to manipulate the server parameters that returns what becomes the first argument to loadServerData. I suppose you could ignore that and just do everything in the loadServerData callback. You should be able to do what you’re after using that.

If you notice how frequently loadServerData is called, you might consider implementing a caching solution to improve performance. I did exactly that, and it worked great for performance and response times.

[TP_DTNAParticipant]

If you bypass the built-in filtering system, you can achieve almost anything with the virtualmode=true setting and server-side queries. But virutalmode is extremely bug-ridden, and the jqwidgets team isn’t very responsive about fixing things (even when I send them actual code for bugfixes).

Check into the loadserverdata callback function, and maybe try googling for my handle along with “virtualmode” to save yourself some hassle.

You could also try gathering your data and then loading it into a grid that uses localdata. Basically just bypass all the built-in stuff and dumb it down for the widgets as best you can.

In other words, handle the filtering yourself separately, then display it with the grid.

[TP_DTNAParticipant]

Like kamelot said, after creating a filtergroup, you would assign the string ‘or’ to its “operator” property.

var filterGroup = new $.jqx.filter();
filterGroup.operator = ‘or’; // column-level OR, not value-level
var filter = filterGroup.createfilter(filtertype, filtervalue, filtercondition);

If your filtering happens client-side, this will work as you desire. If you want it to work on the server side, be careful about using the code provided in the docs/examples as it disregards this information and will always AND the columns together. If you inspect the filter data being sent, you’ll notice that this value is passed as the name of the datafield concatenated with “operator”. Simply tie that into some control flow when constructing the sql query to choose between AND and OR in your WHERE clause between columns.

[TP_DTNAParticipant]

I gave your suggestion a fair try. Should I apply filters before or after loading the state? Should I remove those filters from the state when applying them separately or leave them in? I said “yes” and “no” to these questions and tested them upside down, inside out, backwards, and sideways. While I was able to trigger all kinds of exciting bugs, every single thing I tried still resulted in an unwanted call to loadServerData();

So I took a simpler approach and got pretty close to the result I’m ultimately after with this workaround:
I keep a variable (let’s call it “readyState”) in a scope shared by both the ready function and loadServerData to keep track of the ready state. If loadServerData is called prematurely (before being “ready”), it simply gives an empty data set to the callback as though it made an ajax call that came back with zero results, but without the ajax call and wasted server load.

The ready function then sets that readyState to true so that when loadServerData() is called a second time, it serves up data like normal.

It’s a somewhat lengthy workaround, but gets the job done. To be honest, my experience with the state save and load features (including autosave/load) is that they are quite buggy and would not be very hard to fix and improve. There are many examples, but one is if I try to use the auto features in this setup, it will not apply the filter until after the user has scrolled once, even though the filter icon shows. Seems to be connected to what is happening with the premature data load.

Thanks for your help toward finding a working solution.

Edit: if anyone is also having trouble with virtualmode grids handling empty result sets (like a blank database or empty search query), I found a bug and fixed it: http://www.jqwidgets.com/community/topic/handling-empty-grids-in-virtual-mode/ – That might be required if you implement the fix I described above.

[TP_DTNAParticipant]

While not technically an event, that ready callback approach works much better. Things like the column positions and sizes work great, but for filters and sorts it still displays a non-filtered and non-sorted view before the filters and sort apply and it then loads the correct thing the user should see.

I want to polish my project up to look nice and load correctly the first time without things flickering like that. Is there a way to have the sort and filters apply before it starts making calls to the loadServerData()?

Thank you for the help, the improvement I’ve already gained from your previous suggestion feels nice.

[TP_DTNAParticipant]

I came up with a good solution to this that includes a workaround with the sort event triggering too often. You can clear selections using the sort callback specified in the data source. Just be sure to tuck it into the check for a real sort event so the selections don’t get lost when scrolling.
https://www.jqwidgets.com/community/topic/overactive-sort-event/

[TP_DTNAParticipant]

That’s a demo of how to clear the grid when clicking a button, not how to handle an empty result. At what stage of the process (involving asynchronous callbacks) do you suggest invoking an explicit clear?

The search result is correct in returning zero results, but what is incorrect is how the grid handles that input. Am I asking too much for that simple feature to work correctly like it does in other cases that don’t use virtual mode?

I think I found the exact problem and a neat fix. (jqw version 4.3.0) in jqxdata.js:1838 I changed this line:
if (requestedData.totalrecords) {
to this:
if (requestedData.totalrecords || requestedData.totalrecords === 0) {

and that appears to have resolved the problem completely. I’ll add this patch along with the other fixes in my build process, but it would be nice to get real solutions to issues like this.

[TP_DTNAParticipant]

I’ve figured out a simple modification that appears to do the trick for me, but I’m still testing it out.

[TP_DTNAParticipant]

Thanks, but I’m not sure if we have that and I didn’t find any information on the site about how to get it. We can probably make it happen if it’s an option, and I’ll check into that. Thanks! What I’m ultimately after is this:
“multiplerowsextended” – users can select multiple rows with drag and drop or
by clicking on rows while holding Ctrl or Shift.

I need for that feature to work, and I’m not sure how best to get things fixed other than to tinker with them enough to craft a workaround. Most of the answers I get tend to suggest alternatives that amount to not using the feature I’m trying to resolve in the first place. I do a lot of work with an un-minified version of jqwidgets full of logging code so that I can see what’s happening and what happens internally. It helps me notice certain behavior that is 100% reproducible, and I hope to cultivate some constructive dialogue about undesired behavior (or if it’s not a bug, but a feature!) and how to handle it better.

It appears that the virtual mode feature has a couple rough edges, but otherwise it’s working great for our purposes. Showing data in this way is a really great use of the jqXgrid that I think would delight people who want > 40k rows. I will shed a little tear of joy when the time comes that I see it working 100% as I hope it can, because I know it is possible. Thank you very much for you help and apologies for my rudeness in pursuit of great software.

[TP_DTNAParticipant]

Thank you for acknowledging the issue.

My past experience with contacting the support email was not encouraging, so the forums seem like a better place to start looking for a solution. I have spent a lot of time analyzing jQWidgets code to answer some mysteries not covered in the documentation. If you care to offer me any opportunities to help fix the bug I care most about more directly, I’ll be happy to answer the call. Normally with open source projects, I can fix these things myself and submit a pull request for the maintainer to have at their discretion.

Thank you for the excellent software that we enjoy, use, and rely upon. I look forward to helping ensure quality and shipping a solid product.

[TP_DTNAParticipant]

You looked at my example long enough to dismiss it and disregard it in favor or unrelated examples that neither solve my problem (that I’ve already solved with a dumb workaround) nor exhibit the bug I have neatly demonstrated for you. I stand by my use of the word “ignore”.

Of the three examples you’ve linked, one didn’t even use virtual mode and the other two don’t have much in the way of vertical scrolling. You bring up paging as another way of veering off topic and ignoring the bug I have clearly demonstrated and explained. Providing two of those examples again did not help. If you’re into repetition, try rereading my posts and studying the example I provided.

And then there’s this: “Please note that virtual mode works only with server-side sorting (client-side sorting has no effect in this case).” If you are not interested in fixing bugs for your paying customers, you can simply be straight and truthful with me about it. If you are hoping I will go away by offering unhelpful examples, please know that this isn’t even the jQWidgets bug that’s holding up my project right now.

If you are trying to convince me that you don’t understand how your own software works, then this is a good direction to take. How do you think the grids in my example have content? How would the rendergridrows() callback even know what path that data took to arrive at its feet? The fact that I’m randomly generating it client-side for the sake of this example is as irrelevant as everything else you’ve suggested.

Note this line:
setTimeout(function() { callback(cb_return); }, 10);

Just pretend that is an ajax call to a “server” and look for someone else who can explain it to you if you don’t get that.

The workaround hack I have is good enough for now – I’m okay if you want to leave this issue and put some effort into solving this other one that is holding me up -> http://www.jqwidgets.com/community/topic/multiselect-in-virtualmode/

[TP_DTNAParticipant]

Good news everyone! I improved my hack. The earlier one I posted let one false event slip through and this one is better.
I found out that the sort callback gets two arguments, the field being sorted and a “direction”. On a real sort event, the direction will be one of [true,false,null], which makes a lot of sense and is useful. On subsequent calls that happen upon scrolling (changing the dataview, whatever to call it) that are false sort events, it will send a string like “asc” or “desc”.

AjayTxs, check this out and see if it doesn’t magically fix your issue:

var source = {
    datatype: 'json',
    datafields: dataFields,
    id: 'row',
    url: 'asdasd',
    // minimal sort and filter specification
    filter: function() { $grid.jqxGrid('updatebounddata', 'filter'); },
    sort: function(field, dir) {
      // real sort event
      if(dir === true || dir === false || dir === null) {
        $grid.jqxGrid('updatebounddata', 'sort');
      }
      else {
        console.log('*** FALSE SORT EVENT: ABORT SORT CALLBACK ***');
        return;
      }   
    },
    loadServerData: loSeData,
  };

Dimitar – What you’ve noted are unrelated examples that don’t invoke the virtual mode behavior while also ignoring the example I provided that does invoke the behavior. If you care to provide examples that are relevant, I can show you where this happens, but save yourself the time and simply examine the demo I prepared. I updated it to include the improved hack and to only log instances of the loadServerData callback and the false sort events. http://jsfiddle.net/omjdy9o8/8/

This is a freestanding demo you can run for yourself with your own browser off of jsfiddle. Why are you telling me to check my server and client? Simply run it yourself and see all the false sort events fly down the console. This bug is capable of triggering an infinite loop and was an actual showstopper issue for us until I found a workaround.

Maybe my solution will help others out there, but more of a problem for me right now is the unresolved selection bug, because selecting grid rows is an important requirement for our needs. I have spent a lot of time discovering bugs in jQWidgets and working around them, and I am *more than happy to help* you or your team resolve them directly. I am offering to work directly with your team all day long if it helps me select more than 20 rows at a time.

If you’re ready to suggest that I check for problems, the good news is I have! A lot. They are not with my “client and server”, and you now have several neat demos in your hands of where they actually are. Contact me. The more important problems are taking too long to get fixed and I can help you.

[TP_DTNAParticipant]

To give you an idea, this is my hacky workaround. the lsd_lastSd variable is a string assigned in the loadServerData function from the first argument passed to it. The loadServerData() function gets called and sets that value before the source’s sort callback.

var falseSortHack = '';
  var source = {
    datatype:   'json',
    datafields: dataFields,
    id:         dataPriKey,
    url:        url,
    // lose selections upon sort and filter
    filter: function () { clearselection(); $grid.jqxGrid('updatebounddata', 'filter'); },
    sort:   function () {
      // detect bogus sort event
      var falseSort = lsd_lastSd.replace(/startindex=([^&]*)/, '')
                                .replace(/endindex=([^&]*)/,   '');
      if(falseSort === falseSortHack) {
        console.log('*** FALSE SORT EVENT ***');
        return;
      }
      else {
        console.log('REAL SORT EVENT');
        falseSortHack = falseSort;
        clearselection(); $grid.jqxGrid('updatebounddata', 'sort');
      }
    },
    formatdata:     buildQueryString,
    loadServerData: loadServerData,
  };

[TP_DTNAParticipant]

I’m having a similar problem, but with multiselection. It will only select the rows it can see, not the rows I’m telling it to select. With Dimitar’s demo for instance, select the first row then scroll down a little (row 30 should do it) and then click another row while holding shift to select the range. Now scroll up and you will notice that the first rows beyond the grid’s internal visibility are not selected.

Do I need to implement a superficial selection system that manages the selections and signals the grid for presentation to select the really selected rows when they come into visibility? I’ve already coded out similar workarounds for things like this that don’t work.

edit: I put Dimitar’s demo into a fiddle here where you can see the behavior I describe: http://jsfiddle.net/L9x0L0jv/

[TP_DTNAParticipant]

While the provided client-side grid features, especially filtering, mostly work (with the glaring exception of a string != condition), the slow performance became a real showstopper once our data sizes became interesting. By doing these features server-side with a virtual mode grid, we were able to deliver good interface response time once I implemented the solution I described above. It’s not much more of a cache design than the data adapter’s records property, but it’s a tiny layer meant to feed the poorly designed request mechanism that calls loadServerData more frequently than necessary.

Really, it’s just a simple look-ahead with sequential read access instead of redundantly re-reading most of the data plus tiny increments of new data.

Like driving a car with one’s eyes open instead of shuffling one’s feet blindfolded with their hands out.

[Author]

Posts