PDA

View Full Version : 4.1 beta layout problem - widthModel.calculated



ExtJSNinjas
27 Dec 2011, 10:45 AM
One of our layouts is failing. In the layout diagnostics layer, we see the failure within the checkAuthority function because me.target.ownerLayout is true, and widthModel.calculated is false (model.calculated).

The error is: [E] contextScreen<container> cannot set width.

Is anyone else seeing issues like this? Thanks.

mitchellsimoens
27 Dec 2011, 11:05 AM
When you say one of your layouts is it a custom layout? if so, this is one of the things that is said to be affected by the layout changes that had to be made.

dongryphon
27 Dec 2011, 11:10 AM
The checkAuthority function is a bit too aggressive here I think and throws an exception. We wanted it that strict for our development, but it is actually not helpful here.

Could you convert the Ext.Error.raise statement in checkAuthority into:



Ext.log.error(setBy + ' should not set ' + prop);


?

That should let you get to the rest of the diagnostic that explains what is happening when you don't load the diagnostic layer.

Once that runs you should have a lot of stuff in the console which you could analyze and/or post here. I think the format may be hard to deduce unless you've used it a lot. ;)

Sorry for the hassle.

ExtJSNinjas
27 Dec 2011, 1:13 PM
Yes, it is a custom layout. I made that change in ContextItem.js, thanks.

I was actually able to get a little further by not adding my configuration object to the items collection before callParent in initComponent. Now, after initComponent, I'm calling the add function on the container.

However, layout woes are not over. I am seeing multiple errors that look like this now:

[E] Layout left connected: container-1006<anchor>

as well as:

[E] Registering duplicate id (id here) with this manager

Any thoughts? This is a pretty dynamic system, with many different types of controls dynamically added to the main layout.

evant
27 Dec 2011, 1:36 PM
The latter error indicates components with duplicate id's are being created. I'd suggest eliminating this first since it's likely going to cause other issues during development.

ExtJSNinjas
27 Dec 2011, 1:41 PM
I will look into this.

Our code was not changed; it was just running in 4.0.7 without issue. Why would this be breaking in the new version? Thanks.

dongryphon
27 Dec 2011, 2:13 PM
I will look into this.

Our code was not changed; it was just running in 4.0.7 without issue. Why would this be breaking in the new version? Thanks.

It's hard to say where a duplicate component id could have come up, but a JS error could have prevented some cleanup from taking place and left a dangling reference.

How complex is your custom layout? Converting a layout can be simple or difficult depending on what it is doing. I am happy to help if you have questions on this part.

ExtJSNinjas
27 Dec 2011, 2:15 PM
It looks like I've been able to resolve most of those types of id related issues with a similar fix to which I've already alluded to: not setting this.items in initComponent, but instead calling add on the container after calling the parent. I am still getting the occasional "should not set width" though.

I am also getting framework warnings, though, such as:

[W] BAD! gridcolumn-1108.height set by gridcolumn-1108<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! gridcolumn-1128.height set by gridcolumn-1128<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! gridcolumn-1109.height set by gridcolumn-1109<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! headercontainer-1107.containerChildrenDone set by gridcolumn-1117<columncomponent> and gridcolumn-1109<columncomponent>
ext-all-dev.js:6570[W] BAD! headercontainer-1107.childrenDone set by gridcolumn-1117<columncomponent> and gridcolumn-1109<columncomponent>

Is this normal?

dongryphon
27 Dec 2011, 2:25 PM
[E] Layout left connected: container-1006<anchor>

This is some missing cleanup that should happen at the end of the layout run ... in this case the 'ownerContext' reference should have been set to null.

This could happen if the layout run fails, or if there is a JS error during the layout or possibly the duplicate id. Also possibly a bug. I don't think it would effect your initial layout, but might impact subsequent runs.

Does you layout derive from anchor? Maybe a missing callParent or something.

dongryphon
27 Dec 2011, 2:31 PM
It looks like I've been able to resolve most of those types of id related issues with a similar fix to which I've already alluded to: not setting this.items in initComponent, but instead calling add on the container after calling the parent. I am still getting the occasional "should not set width" though.

I am also getting framework warnings, though, such as:

[W] BAD! gridcolumn-1108.height set by gridcolumn-1108<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! gridcolumn-1128.height set by gridcolumn-1128<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! gridcolumn-1109.height set by gridcolumn-1109<columncomponent> and headercontainer-1107<gridcolumn>
ext-all-dev.js:6570[W] BAD! headercontainer-1107.containerChildrenDone set by gridcolumn-1117<columncomponent> and gridcolumn-1109<columncomponent>
ext-all-dev.js:6570[W] BAD! headercontainer-1107.childrenDone set by gridcolumn-1117<columncomponent> and gridcolumn-1109<columncomponent>

Is this normal?

The diag layer has warnings "dialed up to 11" as it were, so it is very picky. These are redundant sets to properties, so a wee bug (efficiency most likely) in the layout that "ought not" set the height. The 'childrenDone' is actually a non-issue since that property will be set to true by the last child layout to complete.

Do you have the layout tree as well? It is quite large for most apps, but it is usually where the root cause is found. Most of the time some value is needed by layout A that should have been calculated by layout B, but for some reason that calculation is either not working or not happening.

ExtJSNinjas
27 Dec 2011, 2:39 PM
No, it is not an anchor layout. We have a complex layout containing nested border layouts, basically.

In regards to the "should not set width" errors...

It looks like this line in finishAxis is having an issue; it is trying to subtract a number from NaN (this is triggered from layout.calculate(ownerContext), which calls calculate. See below - size is NaN

center['set' + axis.sizePropCap](size - center.getMarginInfo()[axis.sizeProp]);

ExtJSNinjas
27 Dec 2011, 2:42 PM
How do I retrieve the layout tree? I do see what appears to be a tree-like structure after the "FAILURE" statements in the console. Is that what you are looking for?

Thanks.

dongryphon
27 Dec 2011, 3:15 PM
In regards to the "should not set width" errors...

It looks like this line in finishAxis is having an issue; it is trying to subtract a number from NaN (this is triggered from layout.calculate(ownerContext), which calls calculate. See below - size is NaN

center['set' + axis.sizePropCap](size - center.getMarginInfo()[axis.sizeProp]);

NaN propagation is actually valid during a layout. It was much easier than explicitly testing every piece of a calculation, so we tend to test the results in a few key places. When a width or height is NaN, we recognize that the calculation is not complete and don't signal layouts that want those values.

When a layout does not complete its calculations, we set the "done" flag to false before returning from the "calculate" method and that layout will be rescheduled later.

dongryphon
27 Dec 2011, 3:16 PM
No, it is not an anchor layout. We have a complex layout containing nested border layouts, basically.

Is this a class derived from Ext.layout.container.Container ? Or just a configuration of border layouts?

dongryphon
27 Dec 2011, 3:18 PM
How do I retrieve the layout tree? I do see what appears to be a tree-like structure after the "FAILURE" statements in the console. Is that what you are looking for?

Thanks.

Yes, that is the layout tree. It contains entries for every running layout and the properties it is consuming. You can post it if you like. That will probably help me understand what is happening.

ExtJSNinjas
27 Dec 2011, 3:25 PM
Is this a class derived from Ext.layout.container.Container ? Or just a configuration of border layouts?

Yes. Our viewport has a layout of fit, and a child panel with a border layout (we had to do it this way with one level of nesting). Our main center panel is highly dynamic, with various controls (grids, trees, forms, etc) being destroyed and created, as needed.

ExtJSNinjas
27 Dec 2011, 3:40 PM
Yes, that is the layout tree. It contains entries for every running layout and the properties it is consuming. You can post it if you like. That will probably help me understand what is happening.

Will do. Alternatively, is there a way to submit this to you privately? Thanks.

dongryphon
27 Dec 2011, 3:54 PM
Yes.

Yes = derived from Ext.layout.container.Container?

or

Yes = configuration of border layouts?

;)

dongryphon
27 Dec 2011, 3:55 PM
Will do. Alternatively, is there a way to submit this to you privately? Thanks.

If there is sensitive content, we can go that way. Otherwise, the discussion will probably help others.

ExtJSNinjas
27 Dec 2011, 4:36 PM
If there is sensitive content, we can go that way. Otherwise, the discussion will probably help others.

Here's the console output from one screen (content is dynamically added):

[E] ----------------- FAILURE -----------------
ext-all-dev.js:6570++vp<fit> - size: configured/configured
ext-all-dev.js:6570 ++vpPanel<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++nb<autocomponent> [isBoxParent] - boxChildren: undefined/4 - size: calculated/configured
ext-all-dev.js:6570 ++nb<hbox> [isBoxParent] - boxChildren: undefined/4 - size: calculated/configured
ext-all-dev.js:6570 ++tbfill-1023<autocomponent> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++button-1024<button> [isBoxParent] - boxParent: nb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbspacer-1025<autocomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++button-1026<button> [isBoxParent] - boxParent: nb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbspacer-1027<autocomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++mailStatus<button> [isBoxParent] - boxParent: nb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbspacer-1028<autocomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++button-1029<button> [isBoxParent] - boxParent: nb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++vpPanel<container> - size: calculated/calculated
ext-all-dev.js:6570 ++bb<dock> - size: calculated/configured
ext-all-dev.js:6570 ++bb<container> - size: calculated/configured
ext-all-dev.js:6570 ++panel-1036<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++panel-1036<fit> - size: calculated/calculated
ext-all-dev.js:6570 ++panel-1037<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++toolbar-1030<autocomponent> [isBoxParent] - boxChildren: undefined/4 - size: calculated/configured
ext-all-dev.js:6570 ++toolbar-1030<hbox> [isBoxParent] - boxChildren: undefined/4 - size: calculated/configured
ext-all-dev.js:6570 ++tbfill-1031<autocomponent> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++tbtext-1032<autocomponent> [isBoxParent] - boxParent: toolbar-1030 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbtext-1033<autocomponent> [isBoxParent] - boxParent: toolbar-1030 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1034<button> [isBoxParent] - boxParent: toolbar-1030 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1035<button> [isBoxParent] - boxParent: toolbar-1030 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++panel-1037<autocontainer> - size: calculated/calculated
ext-all-dev.js:6570 ++mc<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++mc<container> - size: calculated/calculated
ext-all-dev.js:6570 ++nav<dock> - size: configured/calculated
ext-all-dev.js:6570 ++nav<container> - size: configured/calculated
ext-all-dev.js:6570 ++navtb<dock> - boxChildren: undefined/6 - size: calculated/configured
ext-all-dev.js:6570 ++navtb<autocontainer> - boxChildren: undefined/6 - size: calculated/configured
ext-all-dev.js:6570 ++toolbar-1045<autocomponent> - boxParent: navtb - size: natural/configured
ext-all-dev.js:6570 ++toolbar-1045<hbox> - boxParent: navtb - size: natural/configured
ext-all-dev.js:6570 ++nb-1040<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++nb-1041<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++nb-1042<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++nb-1043<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++nb-1044<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbfill-1046<autocomponent> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++button-1038<button> [isBoxParent] - boxParent: navtb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++bp<dock> - boxParent: navtb - size: natural/configured
ext-all-dev.js:6570 ++bp<autocontainer> - boxParent: navtb - size: natural/configured
ext-all-dev.js:6570 ++label-1047<autocomponent> - boxParent: bp - size: natural/shrinkWrap
ext-all-dev.js:6570 ++navp<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++navp<card> - size: calculated/calculated
ext-all-dev.js:6570 ++mt<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++toolbar-1070<autocomponent> [isBoxParent] - boxChildren: undefined/2 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++toolbar-1070<hbox> [isBoxParent] - boxChildren: undefined/2 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++tbtext-1071<autocomponent> [isBoxParent] - boxParent: toolbar-1070 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++navigationButton<button> [isBoxParent] - boxParent: toolbar-1070 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++headercontainer-1067<autocomponent> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++headercontainer-1067<gridcolumn> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++treecolumn-1068<columncomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++mt<fit> - size: calculated/calculated
ext-all-dev.js:6570 ++treeview-1069<autocomponent> - size: calculated/calculated
ext-all-dev.js:6570 ++panel-1048<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++panel-1048<container> - size: calculated/calculated
ext-all-dev.js:6570 ++cp<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++cp<card> - size: calculated/calculated
ext-all-dev.js:6570 ++cxts<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++toolbar-1073<autocomponent> [isBoxParent] - boxChildren: undefined/6 - size: calculated/configured
ext-all-dev.js:6570 ++toolbar-1073<hbox> [isBoxParent] - boxChildren: undefined/6 - size: calculated/configured
ext-all-dev.js:6570 ++button-1074<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1075<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1076<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1077<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1078<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++button-1079<button> [isBoxParent] - boxParent: toolbar-1073 - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++cxts<container> - size: calculated/calculated
ext-all-dev.js:6570 ++ks-1081<dock> - size: configured/calculated
ext-all-dev.js:6570 ++ks-1081<fit> - size: configured/calculated
ext-all-dev.js:6570 ++kgr<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++kgr<container> - size: calculated/calculated
ext-all-dev.js:6570 ++inb<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++inb_pb<autocomponent> [isBoxParent] - boxChildren: undefined/2 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++inb_pb<hbox> [isBoxParent] - boxChildren: undefined/2 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++button-1108<button> [isBoxParent] - boxParent: inb_pb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbfill-1109<autocomponent> [isBoxParent] - size: calculated/configured
ext-all-dev.js:6570 ++gearButton_inb<button> [isBoxParent] - boxParent: inb_pb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++inb_bb<autocomponent> [isBoxParent] - boxChildren: undefined/6 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++inb_bb<hbox> [isBoxParent] - boxChildren: undefined/6 - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++tbtext-1091<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++inb_src<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbtext-1092<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++inb_prsn<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++tbtext-1093<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++inb_trc<autocomponent> [isBoxParent] - boxParent: inb_bb - size: shrinkWrap/shrinkWrap
ext-all-dev.js:6570 ++headercontainer-1110<autocomponent> [isBoxParent] - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++headercontainer-1110<gridcolumn> [isBoxParent] - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++gridcolumn-1130<columncomponent> [isBoxParent] - size: configured/calculated
ext-all-dev.js:6570 ++gridcolumn-1112<columncomponent> [isBoxParent] - size: configured/calculated
ext-all-dev.js:6570 ++gridcolumn-1113<columncomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++gridcolumn-1114<columncomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++gridcolumn-1115<columncomponent> [isBoxParent] - size: configured/shrinkWrap
ext-all-dev.js:6570 ++inb<fit> - size: calculated/calculated
ext-all-dev.js:6570 ++gridview-1116<autocomponent> - size: calculated/calculated
ext-all-dev.js:6570 ++ks-1081-splitter<autocomponent> - size: configured/calculated
ext-all-dev.js:6570 ++k132502842261740474<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++k132502842261740474<card> - size: calculated/calculated
ext-all-dev.js:6570 ++sel-1117<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++sel-1117<fit> - size: calculated/calculated
ext-all-dev.js:6570 ++frm-1118<dock> - size: calculated/calculated
ext-all-dev.js:6570 ++frm-1118<anchor> - size: calculated/calculated
ext-all-dev.js:6570 --kv-1124<fit> - size: calculated/calculated
ext-all-dev.js:6570 triggeredBy: count=2
ext-all-dev.js:6570 kv-1124-bodyEl.height () dirty: false, setBy: ?
ext-all-dev.js:6570 kv-1124-bodyEl.width (1269) dirty: false, setBy: kv-1124<fieldcontainer>
ext-all-dev.js:6570 --kvitem-1125<dock> - size: calculated/calculated
ext-all-dev.js:6570 triggeredBy: count=2
ext-all-dev.js:6570 kvitem-1125.height () dirty: false, setBy: ?
ext-all-dev.js:6570 kvitem-1125.width (1269) dirty: false, setBy: kv-1124<fit>
ext-all-dev.js:6570 ++kvitem-1125<fit> - size: calculated/calculated
ext-all-dev.js:6570 ++kds-1120<field> - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++kstr-1122<textfield> - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++kstr-1123<textfield> - size: calculated/shrinkWrap
ext-all-dev.js:6570 ++kv-1124<fieldcontainer> - size: calculated/calculated

ExtJSNinjas
27 Dec 2011, 4:45 PM
Is this a class derived from Ext.layout.container.Container ? Or just a configuration of border layouts?

Sorry, I'm 100% really clear on which class you are referring to.

We have an Ext.panel.Panel inside of our Viewport (fit layout), which is a border layout (created initially with configs). The border layout within the main center panel contains mostly other types of panels (grid, tree, etc) that are dynamically added to the main center panel (configs) depending on the context. On the west is a tree used for navigation, and to the north are various controls and toolbars.

Please let me know what I am missing. Thanks for your insight.

dongryphon
28 Dec 2011, 2:28 AM
Sorry, I'm 100% really clear on which class you are referring to.

We have an Ext.panel.Panel inside of our Viewport (fit layout), which is a border layout (created initially with configs). The border layout within the main center panel contains mostly other types of panels (grid, tree, etc) that are dynamically added to the main center panel (configs) depending on the context. On the west is a tree used for navigation, and to the north are various controls and toolbars.

Please let me know what I am missing. Thanks for your insight.

I was curious if you have implemented your own layout class. That is, a class derived from Ext.layout.container.Container. Things are much more exciting moving to 4.1 if you have implemented your own layout classes.

It sounds like you are just configuring standard layouts and using then in dynamic ways (not just setup a instantiation time).

dongryphon
28 Dec 2011, 2:29 AM
Sorry, I'm 100% really clear on which class you are referring to.

We have an Ext.panel.Panel inside of our Viewport (fit layout), which is a border layout (created initially with configs). The border layout within the main center panel contains mostly other types of panels (grid, tree, etc) that are dynamically added to the main center panel (configs) depending on the context. On the west is a tree used for navigation, and to the north are various controls and toolbars.

Please let me know what I am missing. Thanks for your insight.

I was curious if you have implemented your own layout class. That is, a class derived from Ext.layout.container.Container. Things are much more exciting moving to 4.1 if you have implemented your own layout classes.

It sounds like you are just configuring standard layouts and using then in dynamic ways (not just setup a instantiation time).

ExtJSNinjas
28 Dec 2011, 8:35 AM
I was curious if you have implemented your own layout class. That is, a class derived from Ext.layout.container.Container. Things are much more exciting moving to 4.1 if you have implemented your own layout classes.

It sounds like you are just configuring standard layouts and using then in dynamic ways (not just setup a instantiation time).

Is there an example with custom layout classes deriving from Ext.layout.container.Container that we can look at? Thanks.

dongryphon
28 Dec 2011, 11:41 AM
Is there an example with custom layout classes deriving from Ext.layout.container.Container that we can look at? Thanks.

There is the "center" layout in the layout browser, but it is pretty unique to being a form of "fit" layout.

The best thing would be to look at a core layout that is close to your needs and model yours after that.

I would be curious to know what you need in a custom layout, if you could share. :) This is a complex thing to build (always was really and is more so in 4.1) so I would not encourage folks to build their own layouts unless they need to do so. And if there are common needs out there, I would like to see if we can extend the set of core layouts to better address them.

Not to say writing custom layouts is a no-no or bad practice. Rather it is a challenge to write one that is efficient (as we have witnessed first-hand internally during 4.1 development).

dongryphon
28 Dec 2011, 12:00 PM
Here's the console output from one screen (content is dynamically added):

[E] ----------------- FAILURE -----------------
++k132502842261740474<card> - size: calculated/calculated
++sel-1117<dock> - size: calculated/calculated
++sel-1117<fit> - size: calculated/calculated
++frm-1118<dock> - size: calculated/calculated
++frm-1118<anchor> - size: calculated/calculated
--kv-1124<fit> - size: calculated/calculated
triggeredBy: count=2
kv-1124-bodyEl.height () dirty: false, setBy: ?
kv-1124-bodyEl.width (1269) dirty: false, setBy: kv-1124<fieldcontainer>

--kvitem-1125<dock> - size: calculated/calculated
triggeredBy: count=2
kvitem-1125.height () dirty: false, setBy: ?
kvitem-1125.width (1269) dirty: false, setBy: kv-1124<fit>

++kvitem-1125<fit> - size: calculated/calculated
++kds-1120<field> - size: calculated/shrinkWrap
++kstr-1122<textfield> - size: calculated/shrinkWrap
++kstr-1123<textfield> - size: calculated/shrinkWrap
++kv-1124<fieldcontainer> - size: calculated/calculated





The root cause goes like this:

kv-1125's dock layout never got a height ("height ()" should be "height (100)" or something).

Because kv-1124's fit layout never gave it one ("calculated/calculated" means the fit layout will be calculating width/height).

Because kv-1124's fit layout never got its container's height ("bodyEl.height ()").

Probably because kv-1124's component layout (fieldcontainer) never gave it one.

Perhaps you could focus on that small part and make an example out of it?

btw... there might be some over-nesting of containers as well. This would be a performance issue only (not a huge one probably). The card layout has a panel (sel-1117) w/fit layout and just a single panel (frm-1118). Perhaps frm-1118 could be moved up and sel-1117 removed. Sometimes these are architecturally induced, but just wanted to mention it as a potential optimization.

ExtJSNinjas
28 Dec 2011, 1:23 PM
The root cause goes like this:

kv-1125's dock layout never got a height ("height ()" should be "height (100)" or something).

Because kv-1124's fit layout never gave it one ("calculated/calculated" means the fit layout will be calculating width/height).

Because kv-1124's fit layout never got its container's height ("bodyEl.height ()").

Probably because kv-1124's component layout (fieldcontainer) never gave it one.

Perhaps you could focus on that small part and make an example out of it?

btw... there might be some over-nesting of containers as well. This would be a performance issue only (not a huge one probably). The card layout has a panel (sel-1117) w/fit layout and just a single panel (frm-1118). Perhaps frm-1118 could be moved up and sel-1117 removed. Sometimes these are architecturally induced, but just wanted to mention it as a potential optimization.

Commenting out one of the kv "layout: 'fit'" settings seems to have stopped those errors. Thanks for the input.

Now I am seeing "Layout left connected: container-1106<anchor>" errors. Does this mean that there is a container with an "anchor" layout set, or with the "anchor" property set? I don't get a tree with this error message.

We do have to keep the card layout, as it is used with dynamic controls in other contexts. Thanks, though.

dongryphon
28 Dec 2011, 1:54 PM
Commenting out one of the kv "layout: 'fit'" settings seems to have stopped those errors. Thanks for the input.

Just curious which setting. If it is working for you, obviously your time will probably be focused elsewhere now... which is fine :)


Now I am seeing "Layout left connected: container-1106<anchor>" errors. Does this mean that there is a container with an "anchor" layout set, or with the "anchor" property set? I don't get a tree with this error message.

This message indicates that some layout didn't get a per-run property cleared. Not sure how that happens yet, but its effects are probably minor. We need to clear this up though since it will probably have some bad effects. Holding on to memory it does not need at a minimum.


We do have to keep the card layout, as it is used with dynamic controls in other contexts. Thanks, though.

I was actually looking at the two panels inside the card. The immediate child of the card (sel-1117) has a single child (frm-1118) that is 'fit' so you may not need sel-1117 and might be able to make frm-1118 a child of the card. Again, lots of "maybe" in that.

ExtJSNinjas
28 Dec 2011, 4:56 PM
I have a question that is related to the duplicate id messages that I was seeing earlier in this thread. When a control (and thus sub-controls) is destroyed, is it no longer unregistered from either Ext.AbstractManager or Ext.ComponentManager? This seems to be the case now.

tvanzoelen
29 Dec 2011, 7:50 AM
That [E] Layout left connected: form-1025<anchor> I have multiple times.
In my case it is in the form.

dongryphon
29 Dec 2011, 10:57 AM
I have a question that is related to the duplicate id messages that I was seeing earlier in this thread. When a control (and thus sub-controls) is destroyed, is it no longer unregistered from either Ext.AbstractManager or Ext.ComponentManager? This seems to be the case now.

The destroy method does call the ComponentManager unregister method. Which is actually in AbstractManager.

Do you have an example by chance that produces duplicate ids?

mkjellman
9 Jan 2012, 3:54 PM
i am also running into this problem. It looks like it is related to forms only.

"Layout left connected: fieldset-1038<anchor>"
"Layout left connected: fieldset-1081<anchor>"
"Layout left connected: myformnamhere<anchor>"

tvanzoelen
11 Jan 2012, 1:45 AM
You must tell the items how to anchor. Just setting the layout on 'auto' (of forms for example) is a quicker solution.

mkjellman
11 Jan 2012, 9:19 AM
I have a "anchor: 'percentage%' on every item inside a container with a layout of type 'anchor' though, so i believe I already have told the items how to anchor

auto doesn't layout correctly and in 4.0 this layout was fine. in 4.1 it renders correctly as well, just worried about the erorrs

McQuack_82
27 Jan 2012, 1:43 PM
I was experiencing the same issues with the 4.1 version. I switched the layout to a column layout and it fixed the error coming up. I'm not sure why it happening but it seem to on show in the debug and not affect the rendering of the panel.



Ext.create('Ext.form.FormPanel', {
title: 'Order Search',
itemId: 'orderSearchFormPanel',
region: 'west',
width: 200,
split: true,
bodyPadding: 10,
collapsible: true,
layout: 'column',
autoScroll: true,
defaults: {
columnWidth: 1.0,
labelAlign: 'top'
},
defaultType: 'textfield',
items: [
{
fieldLabel: 'Global Search',
name: 'global',
itemId: 'Global'
}
]
});