Success! Looks like we've fixed this one. According to our records the fix was applied for EXTJS-5442 in a recent build.
  1. #1
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    5,010
    Vote Rating
    183
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default [4.1.0B3] Component render, afterrender, beforerender handlers in controller.Control

    [4.1.0B3] Component render, afterrender, beforerender handlers in controller.Control


    I found that in [B3] component render, afterrender, and beforerender (I didn't test others, yet) events will fire fine if I set up a listeners config in my class definition or in an instance of the component, but my app's controller's control method would no longer see the events.

    I discovered that if I put something in the listeners config on the class definition that the controller would see the event.

    *abstract from controller.control()
    Code:
    , 'mygrid': {
        beforerender: function () { console.log('grid afterrender event fired from the controller') }
        , afterrender: function () { console.log('grid afterrender event fired from the controller') }
        , render: function () { console.log('grid render event fired from the controller') }
    }
    By itself the above code works in B2, but not in B3.

    If in mygrid's definition I do the following the above code will fire from the controller (*with afterrender commented out below it won't fire the afterrender event in the controller, but the other two fire - uncomment and all three fire).

    Code:
    , listeners: {
        beforerender: Ext.emptyFn
        , render: Ext.emptyFn
        , afterrender: Ext.emptyFn
    }

  2. #2
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,325
    Vote Rating
    114
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


    See this

  3. #3
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    5,010
    Vote Rating
    183
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default


    I see. Thx.

  4. #4
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,346
    Vote Rating
    134
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    These are different issues. The link above is specifically about the return value of fireEvent. This is a bug in how the MVC EventBus does not get along with the hasListeners optimization.

    Thanks for the report! I'm going to move this to the bugs forum and link a ticket.
    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!"

  5. #5
    Ext JS Premium Member
    Join Date
    Dec 2009
    Posts
    65
    Vote Rating
    3
    oklymenko is on a distinguished road

      0  

    Default


    I see that this bug has just been marked as fixed.

    We noticed that in beta-3 the destroy event is not captured by the controller either. The workaround of defining a Ext.emptyFn listener on the component does not seem to help with this particular event.

    Does this fix address the destroy event as well as beforerender/render/afterrender?

    Thanks.