Document enums?

[Thomas Wagner]

Is it possible to document enums with AppleDocs?  Would be nice to have documentation on the constants that can be used.

[Tomaz Kragelj]

With current version not. I've already added support for it in experimental branch which is where next major release is neing developed. 

Tom

On Saturday, February 9, 2013, Thomas Wagner via appledoc wrote:

Is it possible to document enums with AppleDocs?  Would be nice to have documentation on the constants that can be used.

--
You received this message because you are subscribed to the Google Groups "appledoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appledoc+u...@googlegroups.com.
To post to this group, send email to appl...@googlegroups.com.
Visit this group at http://groups.google.com/group/appledoc?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rob Van der Veer]

Op zaterdag 9 februari 2013 00:53:28 UTC+1 schreef Thomas Wagner het volgende:

> Is it possible to document enums with AppleDocs?  Would be nice to have documentation on the constants that can be used.

Good news. Check this issue at the bottom: https://github.com/tomaz/appledoc/issues/2

[Titus Abraham]

Any idea when this is coming out ? 

[Titus Abraham]

Any idea on when its coming out ?

On Friday, February 8, 2013 10:52:05 PM UTC-8, Tom wrote:

With current version not. I've already added support for it in experimental branch which is where next major release is neing developed. 

Tom

On Saturday, February 9, 2013, Thomas Wagner via appledoc wrote:

Is it possible to document enums with AppleDocs?  Would be nice to have documentation on the constants that can be used.

--
You received this message because you are subscribed to the Google Groups "appledoc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to appledoc+unsubscribe@googlegroups.com.

[Tom @ Gentle Bytes]

Enums are already supported with latest version on GitHub (2.2). Must use NS_ENUM macro.

--

Sent from my iPad

[Raymond Camden]

Should we expect this to work with NS_OPTIONS? I'm seeing weirdness with it for sure.

On Wednesday, September 18, 2013 1:51:00 AM UTC-5, Tom wrote:

Enums are already supported with latest version on GitHub (2.2). Must use NS_ENUM macro.

--

Sent from my iPad

[Tom @ Gentle Bytes]

I didn't implement this feature, but looking into source code it seems
to support both...

On 11 Apr 2014, at 22:17, Raymond Camden via appledoc wrote:

> Should we expect this to work with NS_OPTIONS? I'm seeing weirdness
> with it
> for sure.
>

> --
> You received this message because you are subscribed to the Google
> Groups "appledoc" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to appledoc+u...@googlegroups.com.

> To post to this group, send email to appl...@googlegroups.com.

> Visit this group at http://groups.google.com/group/appledoc.
> For more options, visit https://groups.google.com/d/optout.

[Rob Van der Veer]

I can't remember how i did it, but I did implement NS_OPTIONS. Perhaps the old issue has a clue on notation?

Sorry, but i just forgot.

—
www.simplicate.info

[Raymond Camden]

From what I'm seeing, Appledoc is "one off" in terms of how it reads the source. This is what I've got (pardon the "foo" crap, but I had to hide stuff)

/**

 Startup option flags. 

 */

typedef NS_OPTIONS(NSUInteger, FooOption) {

    EnableFoo           = 1,        /** enable foo */

    ShowFoo2      = 1 << 1,   /** file foo2 */

    ShowFoo3         = 1 << 2,   /** file foo3 */

    SortFoo4   = 1 << 3    /** file foo4 */

};

When generated, it correctly reads "Startup option flags" as the top level documentation. But it then duplicates that for EnableFoo. Then, the next 3 use the *previous* items doc for their doc.

Is this (the way the comments are done above) just the wrong way to write them?

[Raymond Camden]

Boom. Switching to

//* comment */

Foo,

//* comment 2 */

GOo,

Worked perfectly. 

[Tom @ Gentle Bytes]

Exactly - position of comment determines which object it is assigned to. Current version always expects comment in front of the object is describes. (Note that you also need to use double star for comment otherwise it's ignored).

Next major release will support comments the way you want, but you'll need to use special formatting to tell it so:

/**
Startup option flags.
/
typedef NS_OPTIONS(NSUInteger, FooOption) {
EnableFoo = 1, /**< enable foo /
ShowFoo2 = 1 << 1, /**< file foo2 /
ShowFoo3 = 1 << 2, /**< file foo3 /
SortFoo4 = 1 << 3 /**< file foo4 */
};

On 16 Apr 2014, at 17:26, Raymond Camden via appledoc wrote:

Boom. Switching to
//* comment /
Foo,
// comment 2 */
GOo,

Worked perfectly.

On Wednesday, April 16, 2014 10:23:30 AM UTC-5, Raymond Camden wrote:

From what I'm seeing, Appledoc is "one off" in terms of how it reads the
source. This is what I've got (pardon the "foo" crap, but I had to hide
stuff)

/**
Startup option flags.
/
typedef NS_OPTIONS(NSUInteger, FooOption) {
EnableFoo = 1, /* enable foo /
ShowFoo2 = 1 << 1, /* file foo2 /
ShowFoo3 = 1 << 2, /* file foo3 /
SortFoo4 = 1 << 3 /* file foo4 */
};

When generated, it correctly reads "Startup option flags" as the top level
documentation. But it then duplicates that for EnableFoo. Then, the next 3

use the previous items doc for their doc.

Is this (the way the comments are done above) just the wrong way to write
them?

On Monday, April 14, 2014 3:40:36 AM UTC-5, Rob Van der Veer wrote:

I can't remember how i did it, but I did implement NS_OPTIONS. Perhaps
the old issue has a clue on notation?

Sorry, but i just forgot.
—
www.simplicate.info

--

[Raymond Camden]

Cool -just happy I figured it out. :) 

On Wed, Apr 16, 2014 at 10:37 AM, appledoc on behalf of Tom <appl...@googlegroups.com> wrote:

Exactly - position of comment determines which object it is assigned to. Current version always expects comment in front of the object is describes. (Note that you also need to use double star for comment otherwise it's ignored).

Next major release will support comments the way you want, but you'll need to use special formatting to tell it so:

--

===========================================================================
Raymond Camden, Web Developer for Adobe

Email : raymon...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden