PDA

View Full Version : [FIXED][3.1] border layout west containers fire resize event with missing param



jay@moduscreate.com
21 Dec 2009, 8:48 AM
Ext.onReady(function() {
var viewport = new Ext.Viewport({
layout:'fit',
items: [{
xtype: 'tabpanel',
activeTab: 1,
items: [{
title: 'Homepage',
html: 'foobar'
},{
title: 'Query Builder',
layout: 'border',
items: [{
region: 'west',
title: 'Search',
itemId : 'west',
collapsible: true,
width: 300,
layout: 'fit',
listeners: {
resize: function(c, adjWidth, adjHeight, rawWidth, rawHeight) {
console.info('west panel');
console.info(arguments);
}
}
}, {
region: 'center',
title: 'Search results',
xtype: 'container',
itemId : 'center',
items: [],
listeners : {
resize : function() {
console.log('center panel');
console.log(arguments);
}
}
}]
}]
}]
});
});


http://tdg-i.com/img/screencasts/2009-12-21_1148.png

danigoldman
21 Dec 2009, 8:56 AM
Ext version tested:

Ext 3.1.0


Adapter used:

ext


css used:

only default ext-all.css




Browser versions tested against:

Opera 10
IE8
FF3 (firebug 1.4.5 installed)


Operating System:

WinXP


Description:

The 'resize' event doesn't receive the expected adjWidth, adjHeight, rawWidth and rawHeight arguments for non-center panels using the border layout. Instead they are all 'undefined'.


Test Case:



Ext.onReady(function() {
var viewport = new Ext.Viewport({
layout:'fit',
items: [{
xtype: 'tabpanel',
activeTab: 1,
items: [{
title: 'Homepage',
html: 'foobar'
},{
title: 'Query Builder',
layout: 'border',
items: [{
region: 'west',
title: 'Search',
collapsible: true,
width: 300,
layout: 'fit',
listeners: {
resize: function(c, adjWidth, adjHeight, rawWidth, rawHeight) {
console.info('west panel');
console.info(arguments);
}
}
}, {
region: 'center',
title: 'Search results',
xtype: 'container',
items: [],
listeners : {
resize : function() {
console.log('center panel');
console.log(arguments);
}
}
}]
}]
}]
});
});



Steps to reproduce the problem:

Simply load the test case and check the Firebug console.


The result that was expected:

You should be seeing all of the passed arguments of the resize event, including the adjWidth, adjHeight, rawWidth and rawHeight)


The result that occurs instead:

The adjWidth, adjHeight, rawWidth and rawHeight arguements are all undefined (in the West panel).


Debugging already done:

See: http://www.extjs.com/forum/showthread.php?t=88122

hendricd
21 Dec 2009, 10:41 AM
@danigoldman -- Try this override (while the investigation continues... ):




Ext.override(Ext.Panel, {

// private
onResize : function(w, h, rw, rh){
if(Ext.isDefined(w) || Ext.isDefined(h)){
if(!this.collapsed){
// First, set the the Panel's body width.
// If we have auto-widthed it, get the resulting full offset width so we can size the Toolbars to match
// The Toolbars must not buffer this resize operation because we need to know their heights.

if(Ext.isNumber(w)){
this.body.setWidth(w = this.adjustBodyWidth(w - this.getFrameWidth()));
} else if (w == 'auto') {
w = this.body.setWidth('auto').dom.offsetWidth;
} else {
w = this.body.dom.offsetWidth;
}

if(this.tbar){
this.tbar.setWidth(w);
if(this.topToolbar){
this.topToolbar.setSize(w);
}
}
if(this.bbar){
this.bbar.setWidth(w);
if(this.bottomToolbar){
this.bottomToolbar.setSize(w);
// The bbar does not move on resize without this.
if (Ext.isIE) {
this.bbar.setStyle('position', 'static');
this.bbar.setStyle('position', '');
}
}
}
if(this.footer){
this.footer.setWidth(w);
if(this.fbar){
this.fbar.setSize(Ext.isIE ? (w - this.footer.getFrameWidth('lr')) : 'auto');
}
}

// At this point, the Toolbars must be layed out for getFrameHeight to find a result.
if(Ext.isNumber(h)){
h = Math.max(0, this.adjustBodyHeight(h - this.getFrameHeight()));
this.body.setHeight(h);
}else if(h == 'auto'){
this.body.setHeight(h);
}

if(this.disabled && this.el._mask){
this.el._mask.setSize(this.el.dom.clientWidth, this.el.getHeight());
}
}else{
this.queuedBodySize = {width: w, height: h};
if(!this.queuedExpand && this.allowQueuedExpand !== false){
this.queuedExpand = true;
this.on('expand', function(){
delete this.queuedExpand;
this.onResize(this.queuedBodySize.width, this.queuedBodySize.height);
}, this, {single:true});
}
}
this.onBodyResize(w, h);
}
this.syncShadow();
Ext.Panel.superclass.onResize.call(this, w, h, rw, rh);
}
});

danigoldman
21 Dec 2009, 10:50 AM
Thanks Doug. It works with your (temporary) fix.

hendricd
21 Dec 2009, 11:32 AM
Fix posted to SVN 5802.

TheBerliner
4 Feb 2010, 2:12 AM
I doubt that this fix is correct or there is another bug in this code. In my case it changes the height of a panel.

This is the situation:

Ext 3.1 with the above listed fix.

I have added functions to remember the position and size of popup windows to ensure that a user's changes to size and position will be used when they are opened again. These functions are called by the move and resize events and they use the arguments gives by these events.

This worked perfectly fine unter 3.0.

But now Ext 3.1 with this fix changes the height by a fixed amount (by 59px in my case) when the window is created with the old settings so that the height becomes smaller than the one originally passed by the resize event and remembered last time. The width is not changed.

This happens in these lines of code:



// At this point, the Toolbars must be layed out for getFrameHeight to find a result.
if(Ext.isNumber(h)){
h = Math.max(0, this.adjustBodyHeight(h - this.getFrameHeight()));
this.body.setHeight(h);
}else if(h == 'auto'){
this.body.setHeight(h);
}


I have no time to investigate this in more detail, because my Ext project has been delayed by many week due to the very bad state of the documentation and the many bugs and missing infos in the doc. This has cost me weeks during last summer and fall and an awful lot of money.

Also, I strongly recommend Ext to use eXtreme testing methods to improve the quality of future releases. I doubt that a complex system like Ext can be properly tested withut such means, except "in the field" - and this is what seems to happen - costing Ext's customers a lot of time and money. I have excellent experiences with eXtreme test cases for a comparable kernel library in a desk-top dev environment.

When reading how many bugs there are in a new major release, I get the impression that Ext expects such testings to be made and paid by their customers.

Beyond that I protest against censuring my footer and my location information, none of which contained any offensive words or statements. They have been removed twice without giving me any notice. You can still find them in Google cache though.

This is not how one treats customers!

evant
4 Feb 2010, 2:28 AM
What changes the height of the panel? Your description is unclear. I'm not sure what the relation is between the issue you're having and the OP.

TheBerliner
4 Feb 2010, 2:57 AM
I cannot say if this is caused by the OP's issue as I cannot step deeper inside.

What I know for sure is that when I resize a Window to a height of 300px, for example, the height and width are stored correctly from the resize event. I then close it and open a new Window of the same type with the stored size parms.

Width and height are supplied from the (still correctly) remembered last size values and the window is opened but always with a smaller height and with the same width. The height is always reduced by 59px.

I have checked this several times. There is no bug in my part of the code and this worked fine in 3.0.

The change of the given height happens in the quotes code lines above.

Apart from the missing time (see above), I see no sense in getting into an basically undocumented code implementing an undocumented complex container system. Any DTP software, for example, has an explanation of how they calculate their containers and frames that is multiple times more precise and more detailed than the fragments offered by Ext.

evant
4 Feb 2010, 3:01 AM
It's not possible to tell without a test case, else we're merely speculating. There isn't much point in posting an issue without one.

TheBerliner
4 Feb 2010, 3:34 AM
One addition that might help:

The change to the height happens only after a resize event was fired due to a manual resize of the Window. This makes me assume that the bug is probably rather in what resize delivers. In other words, when I re-open the window without a prior resize, the height of the newly opened window is correct and the same as the one of the previous.

But again, this has currently no high priority for me to invest more time in it now.

danigoldman
4 Feb 2010, 6:24 AM
I have also noticed that, however with me the adjusted height is 55px (I simply subtracted 55 to get around this issue).

I assumed that this 55px differential is related somehow to the height of the tabs and toolbar (in my case I'm using a tabpanel). The tab strip and toolbar's height are a combined 55px.

makana
9 Feb 2010, 1:00 AM
What's going wrong here? This thread is marked as FIXED, but hendricd's fix isn't even available in public ExtJS3.1.1? Should be reopened, I think... Please fix this! Thank you very much in advance!

evant
9 Feb 2010, 3:16 AM
It is actually fixed in SVN, it logs all the messages with the appropriate parameters. It will be in 3.1.1.

Jamie Avins
9 Feb 2010, 8:45 AM
Looks like a regression bug. Fixed in svn trunk and branch 3.1.x.