Yikes. This is proving a bunch more difficult than expected. The "appear"
event of the popup window seems to happen BEFORE the bogus scrolling in the
background is triggered. I've also tried "focus", "focusin" on the popup;
those happen too early or not at all; NOW I'm trying to figure out how to
detect that the lists have moved. As a refresher, I have this hierarchy:
container.Scroll -> container.Composite(as a layout.Grid) -> multiple
form.Lists
I've tried setting a "move" listener on each level, but the scroll action is
not detected. Is there a different event that should be firing when the
scroll changes drastically?? And which object should have a listener for the
event, if there is one?
I have verified that the scrollToY() function will get the scrolling set
back correctly again for my lists, but I need to be able to detect when the
jump has taken place.
Thanks,
Ken
On Thu, Nov 11, 2010 at 2:58 PM, Ken MacDonald <[email protected]> wrote:
> Thanks, T. -
> Don't think the exact workaround will do the trick, as it would involve a
> ton of re-structuring, but by browsing bugzilla, discovered Scroll methods
> "getScrollY()" and "scroll ToY()" which seem to get/set the scrolling of the
> child element. I will probably have to set an "appear" handler on the popup
> window so that I can reset the Y scroll position AFTER the window is
> rendered, as that's when the bogus scrolling behavior in IE seems to take
> place. Anyway, think I'm headed in the right direction now.
> Ken
>
>
>
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
