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
    6,062
    Vote Rating
    215
    slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of

      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,483
    Vote Rating
    218
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      0  

    Default


    See this

  3. #3
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    6,062
    Vote Rating
    215
    slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of slemmon has much to be proud of

      0  

    Default


    I see. Thx.

  4. #4
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,512
    Vote Rating
    176
    dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of

      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
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    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.