floatParent changed?

[Animal]

OK, I have EXTJSIV-5416 which covers the topic of "upward" links and how to reconcile all methods which need an upward link.

[westy]

Excellent, thanks Nige

I understand your point about the ownerCt, ownerButton, etc.
I'm normally using my getFloatParent to get at the button that's docked to a grid panel from the buttons child menu; can then go from the button up to the grid. Can tweak as needed for this case.


What about the issues I'm seeing with Ext.Layer being treated like a component (posts 4 & 5 in this thread)?
That was more worrying, and was caused me to give up on 4.1 until a later version was posted...


I've almost got through my current workload so should find some time to try the upgrade to 4.1 again soon. Guessing I should try beta 2, or is there a new drop imminent?
Would hope to be able to get it running before you drop the final release in case have issues; it's a very large application so would expect to get some...

Cheers,
Westy

[Animal]

A Layer should never be treated like a Component.

LoadMask can either be asked to use an Element or a Component as its "target", but it should treat each differently.

If anything is getting confused between a Layer (which is just a fancy Element), and a Component, then something's been switched, and it's a separate bug issue.

Beta 3 is being stabilized now, so no possibly destabilizing bug fixes are being allowed in.

[Animal]

OK, I have fixed the upward axis for Floating components. The upward axis follows ownerCt if available, or floatParent.

Menus already have a getBubbleTarget implementation which tries

this.parentMenu || this.ownerButton || this.callParent(arguments);

So if you have a menu of a grid column, you can find its grid by using CQ:

myColumnMenu.up('tablepanel');

[westy]

Excellent, thanks.