jQWidgets Forums
Forum Replies Created
-
Author
-
February 17, 2015 at 11:47 am in reply to: Possible bug discovered in initial filters Possible bug discovered in initial filters #67233
Thank you for the answer Peter.
Unfortunately, a full sample might be complicated… the software I’m working on is very complex and extracting the “sample” out of context would not make much sense. And the entire code file managing the grid is over 1500 lines long.
I will try however to write an independent code illustrating this issue and paste it here. Will come back with it once the test code is ready.
WaveFebruary 17, 2015 at 11:42 am in reply to: Remove sort without sending data Remove sort without sending data #67231Wait, isn’t it possible to not detect that in the “sort” callback of the dataAdapter ?
sort: function() { $("#mygrid").jqxGrid('updatebounddata', 'sort'); },
It should be simple enough to set a flag before calling “removesort” and exit from the callback instead of doing the updatebounddata.
do_not_update = true; $("#mygrid").jqxGrid('removesort'); do_not_update = false;
And the callback changed like this:
sort: function() { if(do_not_update) return; $("#mygrid").jqxGrid('updatebounddata', 'sort'); },
Maybe it works for you
February 17, 2015 at 11:37 am in reply to: Possible bug discovered in initial filters Possible bug discovered in initial filters #67229I forgot to mention:
– jqx Version 3.6.0
– The error occurs on line 11974 of the source code:if (column.cellsformat) {
Apparently “column” is null. The value above “filters[m].datafield” contains the correct column identifier ( datafield ), and the column exists in the grid.
February 11, 2015 at 5:49 am in reply to: jqxGrid Initial Sorting and Page number jqxGrid Initial Sorting and Page number #66887Ah, it needs to be put in the dataAdapter, not in the grid itself.
Yes, that works, thanks !“autoloadstate” however still doesn’t, unless I check the localStorage() myself before initializing the dataAdapter and Grid and putting that page number into the dataAdapter…. well, at least there is a solution, even if it’s not very straightforward.
I will write to support for more detailed questions.
Thank you !—
Edit: Apparently the same way goes for initial Sorting, it needs to be put in the dataAdapter.
Much more clear now thanks, I’ll review all the demos.February 11, 2015 at 5:37 am in reply to: jqxGrid Initial Sorting and Page number jqxGrid Initial Sorting and Page number #66880Hmz… autoloadstate seems broken in virtual mode.
It attempts to load the last used page ( this.dataview.pagenum = data.pagenum; ) but doesn’t send the parameter to the server “pagenum: 0”, and also is attempting to access rows bigger than “0 to pagesize” in the records array, however the dataAdapter doesn’t contain the correct page number and is loading all results into rows with UID’s 0,1,2… instead of 50,51,52 (or whatever is the uid for the pages bigger than 0)
It does work when the pager changes pagenum ( this._raiseEvent(9, { pagenum: pagenum, oldpagenum: oldpagenum, pagesize: this.dataview.pagesize }); ), but not on autoloadstate
… maybe I can fix this myself in the source …November 21, 2013 at 9:40 am in reply to: Initial filtering with new $.jqx.filter() and data loading Initial filtering with new $.jqx.filter() and data loading #33033Welp…
No love for remotely loaded dataAny chance of planning this feature for some of the next updates ?
I’ve seen other threads in the past with people requesting something like this.
—
Or my suggestion, a way to temporarely disable the auto-reloading of data every time a filter is changed and do a dataBind() when all the parameters have been set/changed.Thanks !
P.S. I asked before a similar thing related to loading of grid state, which would also load the data twice, first in the default original state and again after a custom state has been loaded.
The ability to disable autoupdate/autobind would be wonderful in both cases !October 13, 2013 at 6:34 pm in reply to: Wrong selectedrowindex – Selection and grouping + paging Wrong selectedrowindex – Selection and grouping + paging #30647Improved workaround which seems to work in all cases, grouped, not grouped, first page, last page, any page:
.on('rowdoubleclick', function(event) { // Workaround for a bug related to rowindex introduced in jqx 3 if($(this).jqxGrid('getrootgroupscount') > 0) { var cRows = $(this).jqxGrid('getrows').length; if(event.args.rowindex > cRows) event.args.rowindex -= cRows; } row_data = $(this).jqxGrid('getrowdata', event.args.rowindex); ... do something with row_data ...
(Not very efficient, as it reads all the rows to determine the current loaded rows count, but ok, at least the application works again)
October 13, 2013 at 6:16 pm in reply to: Grid grouping and group order. Grid grouping and group order. #30646Well it wasn’t like that a few weeks ago… groups followed the data ordering.
That date field example for example makes it very weird, and grouping numbers also has the same strange effect.Check this:
http://img18.imageshack.us/img18/436/dxzm.jpgShows the group on field “Flight Date”… with the down pointing arrow [V], the column is definitely sorted downwards
-BUT-
The dates appear ascending, because the groups are automatically sorted ascending.Definitely not an expected behavior…
I hope that this “by design” gets changed back to the way it was, for groups order to follow the data order.
Or even better, a way to choose group ordering from the APIThanks !
October 13, 2013 at 6:06 pm in reply to: Wrong selectedrowindex – Selection and grouping + paging Wrong selectedrowindex – Selection and grouping + paging #30645I tried quick workaround which at first appeared to work, but now it breaks the non-grouped mode:
... .on('rowdoubleclick', function(event) { if(event.args.rowindex > cPageSize) event.args.rowindex -= cPageSize; row_data = $(this).jqxGrid('getrowdata', event.args.rowindex); - do something here with row_data - } .on('pagesizechanged', function(event) { cPageSize = event.args.pagesize; } ...
If there are no groups or grouping is disabled, the values are from 0 to whatever the max is (713 in my case)
When grouping is enabled (no matter how deep the grouping is or on what page I am) the values returned are 25-49On the page which has less rows than the page size, bound index start at not at page size, but at number of rows currently loaded:
I have rows 701-713 visible;console.log on event.args shows:
Object { rowindex=13, visibleindex=1, rightclick=false, more…}
(Visible index 0 is the group row itself)If I clear all groups, it becomes:
Object { rowindex=700, visibleindex=700, rightclick=false, more…}I will try a better workaround for now but really hope that this can be reproduced and fixed.
Thanks !October 13, 2013 at 2:51 pm in reply to: Grid grouping and group order. Grid grouping and group order. #30641Some more information:
– Groups are always sorted ascending, no matter what is chosen in the sorting row –For example, now I tried to group by a “date” field, which was sorted descending, with most recent date on top.
When grouping, it shows the group with the oldest date first…Please remove the automatic group sorting, or give an option, thanks !
July 4, 2013 at 5:48 pm in reply to: Bug with Drag and Drop between lists Bug with Drag and Drop between lists #24523Thank you for responding !
I will experiment with your code and will provide a code sample similar to what my application is doing.
It is kinda hard to extract the code directly because those drag-and-drop lists are part of a complex module with over 40 jqWidgets in it but I’ll try to build a simper and clearer sample which exhibits this problem.—
As for the other issue, thanks for checking !I have experienced the same thing in 2.8.3.
Simply setting another “placeHolder” value doesn’t refresh/redraw the DropDownList.$(“#jqxWidget”).jqxDropDownList({placeHolder: “Select:”}); // would be doing nothing
In my case however, I found a workaround. By specifying the “source” to the DropDownList again, the entire thing is refreshed, so the new placeHolder is considered and displayed:
var source = new $.jqx.dataAdapter({ … });
// when generating the control:
$(“#jqxWidget”).jqxDropDownList({
source: source,
width: 300,
// … etc, other parameters
};// when changing the placeHolder
$(“#jqxWidget”).jqxDropDownList({
placeHolder: “New placeholder”,
source: source
});—
This works !
Good luckp.s. – It’s really a bug, we shouldn’t need to force other values in order to change the placeholder…
Sorry for posting multiple times, but I’ve had bad experience with trying to edit my post (accidentally moved it into another thread) !
So… something which might help debugging:
In the example corresponding to the posted picture:
“getrows” and “getboundrows” methods return an array of 3 items ( which contain the actual data )however,
“getdisplayrows” contains … well, 18 items, 3 “group rows” and 15 “data rows”, from which obviously only the first three are correct.I even attempted to use “deleterow” with a rowid > 3, nothing happens, which is logical, since there are really only 3 rows in the bound data !
My guess is that somewhere in the code where grouping happens there is a missing condition when looping from 0 to PageSize to check if the bound row index actually exists:
Using “getgroup” method on the third (fake) group, returns this:
expanded: true
group: “”
level: 0
subgroups: []
subrows: [undefined, undefined, undefined, 9 more…]
0: undefined
1: undefined
2: undefined
3: undefined
4: undefined
5: undefined
… and so on.Please, pretty please with sugar on top, try to fix this before 1st of July this year, we’re trying to launch the application as version 1.0 RC at that time, which means finally some income, which means jqWidgets licenses … for both the people which will use the system comercially, and also for myself a developer license, …. that means everyone’s happy ! But with this really visible problem it will be very difficult to convince the customers that it’s “working as intended”.
Thank you again !
AlinHello, any update on this matter ?
Over two months since…
I tried everything possible to make the fake group with fake rows disappear, without luckhttp://img22.imageshack.us/img22/6366/gridbug.png
Please tell me you are at least considering fixing this !
It makes using groups very distracting for users … and while it is a great feature, not really usable with this problem.Thank you !
May 19, 2013 at 10:27 am in reply to: Three bugs related to Grid's "loadstate" function: Three bugs related to Grid's "loadstate" function: #21395The forum post ate some lines:
if(state.groups.length == 0 && current_state.groups.length > 0) { // yes to no
$(“#issues-grid”).jqxGrid(‘cleargroups’);
}
if(state.groups.length > 0 && current_state.groups.length == 0) { // no to yes, manually create groups
for(c = 0; c< state.groups.length; c++)
$(“#issues-grid”).jqxGrid(‘addgroup’, state.groups[c]);
}This is the workaround for the bug #1
—
I just noticed that not only the filters, sometimes even the columns or column orders are not restored correctly. It appears that state loading function is attempting to do several things (set columns, set filters, set page/groups) all at once and fails some of them at random.I only noticed the problem when loading very different states ( for example, that have other filters, a different column order and other groupings of data ). If only the column order is changed, it loads correctly. Similar, if only a few filter parameters change, they do load correctly.
-
AuthorPosts