Flex的TabNavigator中tab触发的事件

最近用到TabNavigator，想在那个tabBar上点选的时候触发一个自己的回调方法，可是想象中触发的事件和实际真正应该用到的那个是不一样的！最有意思的是，并不是我一个人遇到这样的困惑，一个老外也和我一个感觉，不知道是是该高兴，还是该怎么的。

 

其实很容易的，就是说点击TabNavigator上的选项卡时触发的是IndexChangedEvent.CHANGE，而不是那个tabIndexChange。

 

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="InitApp()">
<mx:Script>
    <![CDATA[
        import mx.events.IndexChangedEvent;
        private function InitApp():void
        {
            tabnavigator1.addEventListener(IndexChangedEvent.CHANGE,indexChangeHandler);
        }
        function indexChangeHandler(event:IndexChangedEvent):void
        {
            this.currentState='HideReminderEntry';
            mybutton.label=tabnavigator1.getTabAt(tabnavigator1.selectedIndex ).label
//            if (event.triggerEvent is MouseEvent)
//                recordAutomatableEvent(event, false);
//            else
//                recordAutomatableEvent(event.triggerEvent, false);
        }
    ]]>
</mx:Script>

 

 

 

老外原文：

 

--------------------------------------------------------

Getting Around Bug in Adobe Flex: TabControl Inline Event Handling for TabIndexChange Doesn't Work

I ran into this because I wanted to do something funky.  I wanted my Flex app window to change PageStates (and size) whenever the TabIndex changed.  Whether doing this kind of thing is wise in a user interface is yet to be seen -- I did it and it even strikes ME as a bit off the wall -- but it did solve the immediate issue.  The immediate issue was that some of my tabs required a lot of space and some did not.  This left a lot of ugly whitespace.

So, I figured, Flex (Actually Flash under the covers) must have an event handler for changing tabs.  And I was rewarded very quickly:  There is a "TabIndexChange" inline event handler.  For the uninitiated, such a thing looks something like this:

<mx:TabNavigator id="tabnavigator1" tabIndexChange="myHandlerFunction()">

With most other events, this works just fine:  When the event fires, the handler is called.  But it simply doesn't work in this case.  The handler function is never called.

There's a couple of ways to handle this.  One way is to use a TabBar control rather than a TabControl.  The TabBar basically gives you the look and feel of a tabset but more control over what is tabbed.  And the tabIndexChange even calls the handler as one might expect.

I didn't want to do it that way, however.  For one thing, I'm stubborn.  For another, I already had all my controls arranged on the TabNavigator and I didn't want to rip it half to pieces to get functionality that I should already be getting.

Fortunately, there's a solution:  Explicitly declare an event listener.  That looks something like this:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="InitApp()">
<mx:Script>
    <![CDATA[
        import mx.events.IndexChangedEvent;
        private function InitApp():void
        {
            tabnavigator1.addEventListener(IndexChangedEvent.CHANGE,indexChangeHandler);
        }
        function indexChangeHandler(event:IndexChangedEvent):void
        {
            this.currentState='HideReminderEntry';
            mybutton.label=tabnavigator1.getTabAt(tabnavigator1.selectedIndex ).label
//            if (event.triggerEvent is MouseEvent)
//                recordAutomatableEvent(event, false);
//            else
//                recordAutomatableEvent(event.triggerEvent, false);
        }
    ]]>
</mx:Script>

 

Important things to note:

1. The handler must be declared in code, and it should run when the page load is complete.  So, in the mx:Application tag, there is the inline event, creationComplete="InitApp()".
2. Any function name can be used here, but InitApp() is by convention.
3. You'll need the "import mx.events.IndexChangedEvent," or you'll get a class-not-defined error.
4. Wire up the event listener with: 
5. tabnavigator1.addEventListener(IndexChangedEvent.CHANGE,indexChangeHandler);
   
6. Finally, as a very small bonus (I'm learning all this too), there's the commented code talking about "if (event.triggerEvent is MouseEvent)".  So it turns out you can distinguish between whether the event occurred as the result of a keyboard event (likely Tab), or as a mouseevent.  I don't see a use for it here, but it's applicable to ALL events, including, say, Focus() events, where it might have some use.  Flex -- actually, ActionScript, its programming language -- is really nifty.

FYI, as a parting note, as far as I can tell SilverLight is intended to be a direct competitor to Flex.  Flex has somewhere around a seven-year head start.  Don't count Microsoft out, of course -- how many people really use Netscape anymore? -- but on the other hand, you never hear about J++ anymore either.  Bottom line:  Those who are considering SilverLight should also consider Flex.  It's incredibly robust, easy to use, has a full-featured IDE that includes powerful debugging capabilities, and there's lots of great resources on it to help people learn.  I've been using the videos at Lynda.com.  In fact, watching one of them got me over the hump on this issue.  So, I recommend Lynda.com wholeheartedly.

 

 

来自：http://theruntime.com/blogs/be-sharp/archive/2008/03/11/Getting-Around-Bug-in-Adobe-Flex-TabControl-Inline-Event-Handling-for-TabIndexChange-Doesnt-Work.aspx