Hi Oleg, good point.
Anyway I tried removing those lines and there is no measurable difference, so I guess firebug profiler is wrong about it
I realized that maybe you simply mean resizing manually in the browser (not with an api): that should make it easier since I guess if you enlarge a column you just remove width from the nearby column, so
col1_ratio = old_ratio * (new_width / old_width) = 0.5 ( 20 / 15)
col2_ration = 0.4 * ((12 – 5) / 12)
I didn't realize there was an api to set a single col width, which api is that?
what does happen today when setting only the first col from 15 to 20? does the whole grid grow of 5 px or is the 5 px removed from the other columns?
I guess when setting a single column, you just need to renormalize the ratios. how to do that depends on the desired result, in particular if setting a single col width changes the whole table width or if the width difference is redistributed among other columns.
Hi Tony, yes when I played with this I also saw that round() does seem to fix the issue most of the time, but I do not think it is a good idea: even if in most cases things tend to “work out”, using round could mean that the final width of the table may be larger of some pixel of the the reuqested width.
For instance suppose you have 15 columns of 5 pixels and they all get a new width 5.6, so the total width is 15*5.6=84 pixels, you end up with the first 9 columns taking 15*6=90 pixels, now even making the last column of width 0, the table is larger than 84 pixels, which would cause big problems if the table has to fit in a parent that has with 84!
The reason is that when we have only initiall calculation of the ratio after resizing columns and calling the setGridWidth the width of the columns have the initial state
I am not sure I understand what you mean here… let me try to explain what I had in mind in pseudocode
initial size:
tony said:
Until now – no (sorry). There is is no appropriate fix for this bug.
What about the solution I proposed above? did you try and it does not work? I hope to have time to try it myself, but jqgrid internals are still a bit intimidating for me 
Thanks for all your work on jqgrid
By the way, to fix it locally I simply removed those since I am not sure what they were meant to do… the compiler already outputs the min.js file in the dist dir:
So did you see performance problems with this approach? I have been carrying this patch in my local copy and didn't see performance issues, but I'd be interested in knowing since I am not fond of keeping local changes and I need to evaluate if it's worth keeping the patch or now 🙂
Thanks in advance,
I have been looking again at this problem and the issue is due to the following code in setGridWidth:
…
ok, I now created a small testcase
by the time the timeout is removed the last column is wider then the first two
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
Yeah, you are right… it's kind of hard to extract a minimal test case 🙂
Anyway, here is at least the code I am using for the resizing. I'll try to also make a standalone testcase, but it may take a bit
this is the jquery code I use to track the chane of width of the container
I tracked it down further and it seems the root cause is this css rule I have:
.ui-jqgrid.ui-widget-content {
Actually it seems that jqgrid is forcing width=205 on the “mytable-pager_center” td, but I could not figure out where this is done and why…
Well, the grid is large as the whole page and pocking at it with firebug I do not see why the widget should get clipped. I can paper over the problem by overriding the css property myself.
However I posted here in bug because I do not see the reason to set the “overflow: hidden” css property in the first place so I was thinking it should be removed upstream
Awesome!
I created a simple ant file that prepares the distribution, including the minified file. Using ant should be portable to all the system and should not be a problem since YUICompressor is already java based.
If you want to merge it I'd be happy with it, otherwise I'll keep it in my tree,
Thanks!
Copyright 2014 TriRand LtdAll Rights ReservedRSS
Back to Top