-
12 Apr 2012 6:40 AM #11
Using an anchor layout is not going to work for this because I am dealing with a card layout.
Here is a better example of what I am trying to achieve:
Code:Ext.onReady(function() { Ext.create('Ext.container.Viewport', { layout: { type: 'vbox', align: 'stretch' }, items: [ { xtype: 'component', html: 'Header', height: 50 }, { xtype: 'toolbar', items: [ { xtype: 'button', text: 'Screen', handler: function() { Ext.ComponentQuery.query('#screens')[0].getLayout().setActiveItem('screen1'); } }, { xtype: 'button', text: 'Screen2', handler: function() { Ext.ComponentQuery.query('#screens')[0].getLayout().setActiveItem('screen2'); } } ] }, { xtype: 'container', itemId: 'screens', layout: 'card', autoScroll: true, flex: 1, items: [ { xtype: 'container', itemId: 'screen1', minHeight: 400, layout: { type: 'vbox', align: 'stretch' }, items: [ { xtype: 'component', flex: 1, html: 'Screen 1 Part 1', style: 'background-color: orange' }, { xtype: 'component', flex: 1, html: 'Screen 1 Part 2', style: 'background-color: green' } ] }, { xtype: 'container', itemId: 'screen2', minHeight: 500, layout: { type: 'vbox', align: 'stretch' }, items: [ { xtype: 'component', height: 425, html: 'Screen 2 Part 1', style: 'background-color: blue' }, { xtype: 'component', flex: 1, html: 'Screen 2 Part 2', style: 'background-color: yellow' } ] } ] }, { xtype: 'component', html: 'Footer', height: 20 } ] }); });
-
12 Apr 2012 7:22 AM #12
Thanks for that testcase, it will make a good test for the fix.
Search the forum: http://www.google.com/coop/cse?cx=01...%3Az7of1ufqccu
Read the docs too: http://extjs.com/deploy/dev/docs/
Scope: http://extjs.com/forum/showthread.ph...642#post257642
-
23 Apr 2012 2:46 PM #13
You are right that this was a fit layout bug - it never considered that a minWidth/Height could cause overflow and that it should account for that. It needed to account for the presence of scrollbars as it applied the container size to the child as well as when it shrinkwraps the child. Basically, almost a rewrite of the guts of that (formerly simple) layout.
Great catch!
Sadly, it won't make it in 4.1.0, but should be in soon after. I have the fixes on a work branch targeting 4.1.1, so it should appear in nightly builds after GA.Don Griffin
Ext JS Development Team Lead
Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue
"Use the source, Luke!"
-
23 Apr 2012 2:47 PM #14
I should mention that Chrome (only so far) does not want to remove the scrollbar once it goes back to not being needed. I will see what I can do about that, but the only way I've found to remove it is to cycle overflow styles. :P
Don Griffin
Ext JS Development Team Lead
Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue
"Use the source, Luke!"
-
23 Apr 2012 2:54 PM #15
Thanks for the update Don. This is a pretty annoying bug especially during development since bringing up the admin console causes the overflow.
Just so we are clear this is a regression from behavior in 4.0.7. I am assuming that Sencha will be going back to the dot releases only being available to support subscribers model. That makes me sad. Hopefully the pace for 4.2 will be accelerated compared to 4.1 once it gets out the door otherwise I will not see this fix until April 2013.
-
23 Apr 2012 8:05 PM #16
The plan is for 4.1.1 to be released to all users.
Don Griffin
Ext JS Development Team Lead
Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue
"Use the source, Luke!"
-
16 May 2012 10:30 AM #17
This looks better in 4.1.1 but like Don said the vertical scroll bar is not going away in Chrome. In Firefox and IE everything appears to work fine.
-
16 May 2012 10:37 AM #18
This is actually worse in Chrome because the scroll bar is now covering up content.
Success! Looks like we've fixed this one. According to our records the fix was applied for
EXTJSIV-5861
in
4.1.


Reply With Quote