1. #21
    Sencha User renku's Avatar
    Join Date
    Feb 2009
    Location
    Estonia
    Posts
    437
    Vote Rating
    17
    renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold

      0  

    Default


    @BillHubbard: Could you provide a test case that causes this crash. The line that you removed alone in a file doesn't seem to cause any problems, but I'd like to find out what does.

  2. #22
    Sencha User
    Join Date
    May 2011
    Location
    Northern California
    Posts
    255
    Vote Rating
    17
    BillHubbard has a spectacular aura about BillHubbard has a spectacular aura about BillHubbard has a spectacular aura about

      0  

    Default


    Quote Originally Posted by renku View Post
    @BillHubbard: Could you provide a test case that causes this crash. The line that you removed alone in a file doesn't seem to cause any problems, but I'd like to find out what does.
    Unfortunately, I am now unable to recreate this problem. I made a lot of changes in doc-comments and guides since I posted the issue last week, so maybe there was some unusual combination of things that created the problem. The offending file was still open in my editor this morning, so I did undo all the way back to where the issue happened, but now the issue is no longer showing up, so perhaps it was a condition in an adjacent file in the process that got corrected with other changes.

    I'll let you know if I encounter it again.

  3. #23
    Sencha User
    Join Date
    May 2011
    Location
    Northern California
    Posts
    255
    Vote Rating
    17
    BillHubbard has a spectacular aura about BillHubbard has a spectacular aura about BillHubbard has a spectacular aura about

      0  

    Default Open by default

    Open by default


    When the help page opens, the Ext branch is expanded by default. Is there a way to make it closed by default, or to specify a different branch to be open?

  4. #24
    Sencha User renku's Avatar
    Join Date
    Feb 2009
    Location
    Estonia
    Posts
    437
    Vote Rating
    17
    renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold

      0  

    Default


    Actually the logic is that the first node gets expanded if it's expandable. But I guess it's quite a silly logic. I think I'll switch to:

    Code:
    If only one expandable node on root level
       expand the node
    else
       do nothing

  5. #25
    Sencha - Community Support Team SamuraiJack1's Avatar
    Join Date
    May 2008
    Posts
    553
    Vote Rating
    3
    SamuraiJack1 will become famous soon enough

      0  

    Default


    Is it possible to prevent the private classes from appearing in the docs?

  6. #26
    Sencha User renku's Avatar
    Join Date
    Feb 2009
    Location
    Estonia
    Posts
    437
    Vote Rating
    17
    renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold

      0  

    Default


    Currently the only way to exclude a class for docs is to leave it undocumented (or use /* or // comments instead of /**). The only nuisance is that you need to also change the comments of all methods in class. Another option is to simply exclude the file from JSDuck input.

    The main problem is that you don't want anything depending on a class that you have completely hidden. Many of the private classes of Ext JS are really fundamental base classes that you don't want to completely hide.

  7. #27
    Sencha - Community Support Team SamuraiJack1's Avatar
    Join Date
    May 2008
    Posts
    553
    Vote Rating
    3
    SamuraiJack1 will become famous soon enough

      0  

    Default


    I see. Ok, thanks

  8. #28
    Ext JS Premium Member
    Join Date
    Mar 2008
    Location
    Phoenix, AZ
    Posts
    627
    Vote Rating
    10
    zombeerose will become famous soon enough zombeerose will become famous soon enough

      0  

    Default


    I like how the docs display the Requires/Uses classes. However, I noticed that when using the MVC configs for models/stores/views, these are not being interpreted as implicit requires in the docs. Any chance these will be added?

  9. #29
    Sencha User renku's Avatar
    Join Date
    Feb 2009
    Location
    Estonia
    Posts
    437
    Vote Rating
    17
    renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold

      0  

    Default


    Could do. I need to additionally implement @uses and @requires tags to allow covering cases where automatic detection doesn't work.

  10. #30
    Sencha User renku's Avatar
    Join Date
    Feb 2009
    Location
    Estonia
    Posts
    437
    Vote Rating
    17
    renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold renku is a splendid one to behold

      0  

    Default


    JSDuck 3.1.0 now available

    This release includes one breaking change: the --stdout and --json options have been removed and replaced with --export option. Instead of --json use --export=full. Instead of --stdout use --export=full --output=-.

    Another large change is that @alias has been replaced with @inheritdoc which by default inherits documentation from parent class member with the same name. The @alias is now used for explicitly documenting the aliases in Ext.define. So alias: "widget.grid" can be explicitly documented as @alias widget.grid. But for backwards-compatibility it still works if you use alias the old way: @alias SomeClass#method.

    The main addition is that warnings can now be toggled on/off more granularly. For example: --warnings=-link will turn off warnings related to {@link}-s. Another example: --warnings=-all,+image,+link will hide all warnings except those related to links and missing images.

    Another main addition or fix is that private members now hide public members in parent class. The old behavior where private members were simply ignored was counter-intuitive and was several times reported as bug. So now finally it's fixed.

    Mostly I'd call it a cleanup release. Lots of old nagging issues have been fixed and the internals of JSDuck have seen some heavier refactoring. See the full changelog for details.

    Any feedback most welcome as always.